On Tue, 27 Oct 2009, Ross Ridge wrote: > Eric Blake writes: > >The correct workaround is indeed to specify a locale with specific charset > >encodings, rather than relying on plain "C" (hopefully cygwin will > >support "C.ASCII", if it does not already). > > The correct fix is for GCC not to intentionally choose to rely on > implementation defined behaviour when using the "C" locale. GCC can't > portably assume any other locale exists, but can portibly and easily > choose to get consistant output when using the "C" locale.
GCC is behaving properly according to the user's locale (representing English-language diagnostics as best it can - remember that ASCII does not allow good representation of English in all cases). The problem here is not a bug in the compiler proper, it is an issue with how to test the compiler portably - that is, how the testsuite can portably set a locale with English language and ASCII character set in order to test the output the compiler gives in such a locale. (Ideally it would be possible for individual tests to specify other locale character sets to test the output given in those locales as well - for example, to test that in an ISO 8859-1 locale extended characters in identifiers that are in ISO 8859-1 are shown as is in diagnostics while those that are not in ISO 8859-1 are shown as UCNs.) -- Joseph S. Myers jos...@codesourcery.com
