Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.15
-
Visual Studio 2013
Windows 8.1 64bit (Japanese version, default code page: cp932)
Description
ISO-8859 encoding does not have encoding compatibilty against cp932(Windows-31J) which is mainly used in Japanese edition of Windows.
This incompatibility causes following build failure:
~~~
c:\jw\workspace\dmbvc2013\powershell\work\source\storage\connect\frids.h(25): error C2001: 定数が 2 行目に続いています。 [C:\jw\workspace\dmbvc2013\powershell\work\build-vc2013-zip-32\storage\connect\connect.vcxproj]
c:\jw\workspace\dmbvc2013\powershell\work\source\storage\connect\frids.h(26): error C2143: 構文エラー : ';' が 'case' の前にありません。 [C:\jw\workspace\dmbvc2013\powershell\work\build-vc2013-zip-32\storage\connect\connect.vcxproj]
c:\jw\workspace\dmbvc2013\powershell\work\source\storage\connect\frids.h(26): error C2001: 定数が 2 行目に続いています。 [C:\jw\workspace\dmbvc2013\powershell\work\build-vc2013-zip-32\storage\connect\connect.vcxproj]
c:\jw\workspace\dmbvc2013\powershell\work\source\storage\connect\frids.h(27): error C2143: 構文エラー : ';' が 'case' の前にありません。 [C:\jw\workspace\dmbvc2013\powershell\work\build-vc2013-zip-32\storage\connect\connect.vcxproj]
~~~
ISO-8859's `é";' string does not correctly interpret in cp932 env by MSVC.
At least, this curious bug can prevent when "frids.h" is saved by UTF-8 encoding.
Attached "friids.h" is saved with UTF-8 encoding and build log in cp932 environment.
Curious bug indeed because only lines 25, 26, 27 raise an error while many other lines contain the same not understood characters (1, 3, 7, 12, 14, 20, 41, 44)
I am not sure I understood what you said by At least, this curious bug can prevent when "frids.h" is saved by UTF-8 encoding.
Did you mean that saving this file in UTF-8 fixes the bug? If so, thanks for telling me how to fix this bug. Note that the file frcas.h should also be UTF-8 encoded although it is not included in your particular build.
If not, if you work on a source distribution, just remove or comment out lines 35 to 42 into rcmsg.c.
As a matter of fact, all this business is to prepare for future versions that should provide the ability to choose the language used for messages. However, as this bug shows, this is not yet operational and documented.