[Webkit-unassigned] [Bug 27416] Windows build break due to warning C4819

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=27416





--- Comment #6 from Takeshi Yoshino <tyoshino at google.com>  2009-07-23 20:11:42 PDT ---
(In reply to comment #5)
> A long time ago, I filed a bug at http://bugreport.apple.com about QuickTime
> SDK headers having multiple non-ASCII bytes in the comment. I have yet to hear
> back. 
> (bug id is 6469108 )
> 

FYI,

For code page 932 (Japanese),
WebKitSupportLibrary/win/include/ColorSync/ColorSyncDeprecated.h also causes
build problem. It contains \xC4\xB6 in some comment line. Since this file is
contained in WebKitSupportLibrary.zip that is automatically checked MD5 and
extracted into WebKitSupportLibrary directory by build-webkit script, when we
fix these file manually by ourselves, we also have to modify build-webkit
script to skip calling update-webkit-support-libs script (and extract
WebKitSupportLibrary.zip by ourselves).

> Either we have to do what the patch here does or  add a simple script to clean
> up Qt SDK headers because they're not a part of webkit. 
> 
> 
> For WebKitTools/DumpRenderTree/win/TestNetscapePlugin/main.cpp, we should just
> remove a non-ascii character (I made a one-line patch a long time ago, but
> haven't submitted, yet). 
> 
> 
> BTW, this does not happen on Windows with the default codepage set to
> single-byte code pages because most of slots in 0x80 - 0xFF are filled up in
> those code pages. In CJK codepages, most of stand-alone bytes with MSB=1 are
> invalid and lead to C4819.

I've gave up manually fixing these characters one month ago, and changed system
locale of development machine to English. So, I have no problem now. But still
it would be nice to have WebKit build work with these locales..

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.