From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27129 invoked by alias); 28 Oct 2009 15:55:46 -0000 Received: (qmail 27120 invoked by uid 22791); 28 Oct 2009 15:55:45 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from mx20.gnu.org (HELO mx20.gnu.org) (199.232.41.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Oct 2009 15:55:41 +0000 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3As7-0002bz-2t for gcc@gcc.gnu.org; Wed, 28 Oct 2009 11:55:39 -0400 Received: (qmail 3866 invoked from network); 28 Oct 2009 15:55:35 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Oct 2009 15:55:35 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1N3As2-000867-Fd; Wed, 28 Oct 2009 15:55:34 +0000 Date: Wed, 28 Oct 2009 17:34:00 -0000 From: "Joseph S. Myers" To: Ross Ridge cc: gcc@gcc.gnu.org Subject: Re: dg-error vs. i18n? In-Reply-To: <20091028033258.BF47473D0C@caffeine.csclub.uwaterloo.ca> Message-ID: References: <20091028033258.BF47473D0C@caffeine.csclub.uwaterloo.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-10/txt/msg00588.txt.bz2 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