This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: proposed Opengroup action for c99 command (XCU ERN 76)
- From: Ian Lance Taylor <ian at airs dot com>
- To: rridge at csclub dot uwaterloo dot ca (Ross Ridge)
- Cc: Robert Dewar <dewar at adacore dot com>, gcc at gcc dot gnu dot org
- Date: 14 Sep 2005 22:12:07 -0700
- Subject: Re: proposed Opengroup action for c99 command (XCU ERN 76)
- References: <20050915045101.E421FA8547@perpugilliam.csclub.uwaterloo.ca>
rridge@csclub.uwaterloo.ca (Ross Ridge) writes:
> > I was not asking the general question, I was asking how it fails
> > to conform wrt the particular technical issue at hand.
>
> Since GCC doesn't have any code that does (A), (B), or (C) it doesn't
> place a burden on GCC to require it to do (B). That's sufficient to
> answer the techinical issue at hand. While that implies GCC doesn't
> conform, I said so explictly because Paul Eggert said that c99 is often
> implemented using GCC.
I am the opposite of an expert on this topic. But in fact gcc does
appear to have code related to (A), (B), and (C). I repeat those
choices here from Paul's original e-mail:
> A. Convert everything to UCNs in basic source characters as soon
> as possible, that is, in translation phase 1. (This is what
> C++ requires, apparently.)
>
> B. Use native encodings where possible, UCNs otherwise.
>
> C. Convert everything to wide characters as soon as possible
> using an internal encoding that encompasses the entire source
> character set and all UCNs.
Now, see libcpp/charset.c. See the -finput-charset= option. To me
that looks like code which does something related to (A), (B), or (C).
Ian