This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: dg-error vs. i18n?
- From: rridge at csclub dot uwaterloo dot ca (Ross Ridge)
- To: gcc at gcc dot gnu dot org
- Date: Tue, 27 Oct 2009 23:32:58 -0400 (EDT)
- Subject: Re: dg-error vs. i18n?
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.
>As far as I know, the hole is intentional. But if others would like
>me to, I am willing to pursue the action of raising a defect against
>the POSIX standard, requesting that the next version of POSIX consider
>including a standardized name for a locale with guaranteed single-byte
>encoding.
I don't see how a defect in POSIX is exposed here. Nothing in
the standard forced GCC to output multi-byte characters when
nl_langinfo(CHARSET) returns something like "utf-8". GCC chould just
as easily have choosen to output these quotes as single-byte characters
when nl_langinfo(CHARSET) returns something like "windows-1252", or some
other non-ASCII single-byte characters when it returned "iso-8859-1".
Ross Ridge