[TSVN] Sudden crash while editing log message in non-space-sparated-languages(like Japanese)

First, I apologise for poor and incorrect English because I am a Japanese.
I welcome indication about correct English.

After the auto completion feature was added, I came to encounter
sudden crashs while editing log message. After several crashes,
I suspected that this is a small bug caused by the new feature.
So, for every releases after 1.1.2, I first tested for this bug.
But all releases to 1.1.5, and even nightly, this bug was not fixed.

Finally, I looked into the source to find what causes this bug.
Then I found some problems in SciEdit.cpp.
The problems follows:

* Critical
When we do Call(SCI_GETTEXTRANGE,...), the size of
buffer(named as textbuffer) is poorly cared.
In GetWordUnderCursor() and CheckSpelling(), the size is
statically specified as 100(and this is a magic number!).
In GetWordUnderCursor(), the size of buffer is completely unchecked.
In CheckSpelling(), there is a check before SCI_GETTEXTRANGE saying
"if (textrange.chrg.cpMax - textrange.chrg.cpMin < 100)".
But this check seems to lack 1 room for '\0'.
After finding these, I verified that 100 contiguous 'a' cause crash.
I understand that 100 can be enough to store one word of English.
But, for example in Japanese(in my case), one word separated by
whitespaces can easily become larger than 100, because Japanese words
are not separated by whitespaces.
In HEAD or nightly, I can turn off the auto completion feature.
But even in latest official release 1.1.5, I can't.
So I can't let my team to upgrade from 1.1.2.

* Related
In MarkEnteredBugID(), textbuffer is dynamically allocated saying
"new char[end_pos - start_pos + 2]".
But this buffer is deallocated by "delete textbuffer".
I think that this should be "delete [] textbuffer".
Moreover, if we should get exception safety, we can use
CStringA and GetBuffer() instead of unmanaged buffer.
And(more small one) I don't know why we add 2 to the length of text.
I know that 1 is for '\0', but another 1 seems not to be used.

A quick fix for the Critical one might be allocating enough buffer
dynamically like in MarkEnteredBugID().
But then we would have three same codes in one source file, and
the allocation scheme seems to be unstable.
So I think this should be fixed with an appropriate restructuring.

Thanks for great works.
Best regards.

--
k_satoda
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org