YuTao - The logic sounds correct, I believe that twice the input string character count should work. However, it appears that both the buffer in GdGetTextSize, as well as the buffer in GdConvertEncoding will have to be auto-allocated. This is also complicated by the fact that the cc count can be set to -1, and the string length is checked after the call in GdGetTextSize, so that strlen() code may have to be moved up. Thus your patch directly as written will need more code, and cc to be calculated in the case it is -1.
I would jump into this but don't have good test data. Also, use the ALLOCA macro, and call FREEA when done, as not all systems support alloca. Another solution would be to increase the size of the first char buf[2048] in GdGetTextSize and char buf16[1024] in GdConvertEncoding. GdConvertEncoding should count space and not overfill the buffer, there's a comment in that routine to this effect. Let me know how you'd like to proceed. Regards, Greg ----- Original Message ----- From: YuTao To: Greg Haerr ; kavedai Cc: jor...@cosmicpenguin.net ; nanogui@linuxhacker.org Sent: Wednesday, April 28, 2010 4:58 AM Subject: utf8 to utf16 in nanox Hi Greg: In GdGetTextSize (src/engine/devfont.c), it will use GdConvertEncoding to convert the input string (utf8) to utf16 (utf8_to_utf16, when the input is utf8), then get text size in the font (pfont->fontprocs->GetTextSize). You have added a FIXME in it: /*FIXME: if buf is not big enough, buf overflow may cause exceptions!!!!*/ src/engine/devfont.c, line 986 It is really a critical issue. It will crash when input string is large than 520 for a certain ttf font. - unsigned long buf[256]; + unsigned long *buf = (unsigned long *)alloca(2*cc); could you check this patch ? the max of utf8 is 4 bytes, the utf16 is 2 bytes. so the twice of input string should be enough? --------------------------------------- 购物券大派送！
