Re: [scintilla] utfval appears need to be enlarged according to UTF16.

47 views
Skip to first unread message

Neil Hodgson

unread,
Mar 12, 2015, 6:38:38 PM3/12/15
to scintilla...@googlegroups.com
johnsonj:

(reordered)

    Line 2627:         char utfval[4] = "\0\0\0”;

   The main use of AddCharBytes was for narrow character windows which are no longer possible since Windows 9x support was removed. I have removed the narrow character window case with

   The remaining use is for WM_IME_CHAR which I can’t provoke. It probably doesn’t happen when WM_IME_COMPOSITION is handled but the documentation for WM_IME_CHAR doesn’t say when it is needed. If WM_IME_CHAR does not need to be handled, then AddCharBytes isn’t needed.

I am not sure but it appears utfvals need to be enlarged according to UTF16.
 
  char utfval[UTF8MaxBytes+1]= "\0\0\0\0"; 

   Each of these locations uses a length parameter instead of relying on NUL termination so they only need to be UTF8MaxBytes which is 4. Changed 4 to UTF8MaxBytes with
   There was also a potential for an out-of-bounds write in AddCharBytes fixed with

  D:\src\sc354\scintilla\win32\ScintillaWin.cxx.orig (3 hits)
    Line 1400:                         char utfval[4];
    Line 1429:                     char utfval[4];

   Neil

johnsonj

unread,
Mar 17, 2015, 4:15:13 AM3/17/15
to scintilla...@googlegroups.com, nyama...@me.com
I find it very difficult to make wm_ime_char work properly.
It will be called if wm_ime_composition does not handle GCS_RESULTSTR.
I do not understand what character is in wParam.
I have failed in printing chars correctly.
I gave up making it work

While a lot of trials and errors, it turns out AddCharBytes seems a dead function.
And Even if it be called, it will not work since it can not handle utf16 .

It seems OK to remove it, but I am not sure.
We will have to keep an eye on it.


johnsonj

unread,
Mar 17, 2015, 10:08:31 AM3/17/15
to scintilla...@googlegroups.com, nyama...@me.com
http://www.siao2.com/2006/01/24/516693.aspx

A bit about the WM_IME_CHAR message

Neil Hodgson

unread,
Mar 17, 2015, 8:00:59 PM3/17/15
to scintilla...@googlegroups.com
While a lot of trials and errors, it turns out AddCharBytes seems a dead function.
And Even if it be called, it will not work since it can not handle utf16 .

It seems OK to remove it, but I am not sure.
We will have to keep an eye on it.

   This code has a lot of history.

   WM_IME_CHAR first appears in commit 89.

   The commit message “Horizontal scroll bar disabling.” doesn’t explain the IME change so I suspect there were several changes being worked on together. My email records have a year-long gap around this time. The patch disables the start/end composition handling and appears to be for Japanese [from the SetThreadLocale(MAKELCID(932…].

   There are several changes to this code from Korean (twkang) and Japanese users. Most of the messages seem to be about Windows 9x.



   I suspect WM_IME_CHAR, as of release 3.5.2 before Windows 9x support was removed, could only be triggered on Windows 9x. I can trigger the other calls to AddCharBytes from WM_CHAR with 3.5.2 on Windows 7 by changing window registration to ANSI: RegisterClassExW->RegisterClassExA, WNDCLASSEXW -> WNDCLASSEXA, and L”Scintilla”->”Scintilla”.

   But even then WM_IME_CHAR does not occur for me. As it doesn’t occur for you, its been removed. If someone reports a bug because of the change, then we’ll know how to exercise this code. Removal commit:

   While this removes the last use of AddCharUTF(*,*,treatAsDBCS=true) from the Scintilla distribution, there may still be other platforms distributed separately that pass true for treatAsDBCS.

   Neil

johnsonj

unread,
Mar 17, 2015, 9:39:59 PM3/17/15
to scintilla...@googlegroups.com, nyama...@me.com
Thank you for your hard works.
Reply all
Reply to author
Forward
0 new messages