This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: dg-error vs. i18n?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Ross Ridge <rridge at csclub dot uwaterloo dot ca>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 28 Oct 2009 15:55:34 +0000 (UTC)
- Subject: Re: dg-error vs. i18n?
- References: <20091028033258.BF47473D0C@caffeine.csclub.uwaterloo.ca>
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
joseph@codesourcery.com