[EMAIL PROTECTED] (Ross Ridge) writes:
The POSIXy way to do that would be to refer to the LC_CHARSET
environment variable, but then consider
LC_CHARSET=UTF-16 c99 foo.c
where 'foo.c' is in UTF-16 and contains '#include stdio.h',
Not really a problem for a number of reasons. First,
Not really a problem for a number of reasons. First, it's LC_CTYPE
you're thinking of. Second, the narrow character set can only be 16-bits
wide if char is 16-bits. Thirdly, if the character set that LC_CTYPE
selects isn't superset of the POSIX portable character set then result
is
Paul Eggert [EMAIL PROTECTED] writes:
Thanks, everybody, for writing about this.
The standardization process is one of consensus, and if the GCC
developers find some areas of disagreement here I think it unlikely
that the other POSIX implementers will agree with the proposed action.
Hence
The POSIXy way to do that would be to refer to the LC_CHARSET
environment variable, but then consider
LC_CHARSET=UTF-16 c99 foo.c
where 'foo.c' is in UTF-16 and contains '#include stdio.h',
Not really a problem for a number of reasons. First, it's LC_CTYPE
you're thinking of. Second, the
Paul Eggert writes:
Would this weaker action pose an undue burden on GCC? My sense from
the discussion is no, but I'd like to double-check with the experts
I'd say no, but I think the experts might see it as posing no burden
at all on GCC. The burden would be on whomever wants to use GCC to
On Sep 17, 2005, at 3:33 PM, Gabriel Dos Reis wrote:
C++98 came before C99, so who diverged from whom?
You seem to not not how the C++ standard was made. In fact, it come
before C99, like it or not. The intention was that C++ would come up
with a follow on standard that tracked C99, in
Mike Stump [EMAIL PROTECTED] writes:
| On Sep 17, 2005, at 3:33 PM, Gabriel Dos Reis wrote:
| C++98 came before C99, so who diverged from whom?
|
| You seem to not not how the C++ standard was made.
Thank you very much.
| In fact, it come before C99, like it or not.
Oh really? What did I
Gabriel Dos Reis said:
[...]
Good. It seems to me like those who would be spending a great deal of
time and money are not sufficiently convinced by your arguments.
Consequently, it appears that they are not in position to explain your
strong opinion to the committees -- personally, I'm not
Zack Weinberg [EMAIL PROTECTED] writes:
[...]
| Also: why do you care so much about this corner case? I only care from the
| implementation perspective, since I doubt it matters to any real software that
| GCC might compile. I'm pointing out an approach to the problem which would
| avoid
Gabriel Dos Reis said:
Zack Weinberg [EMAIL PROTECTED] writes:
| Gabriel Dos Reis said:
| C++98 came before C99, so who diverged from whom?
|
| It doesn't matter.
Yet, you're you were construeing it as an argument to support your position.
I'm only bringing up the divergence as an
Zack Weinberg [EMAIL PROTECTED] writes:
| Gabriel Dos Reis said:
| Zack Weinberg [EMAIL PROTECTED] writes:
|
| | Gabriel Dos Reis said:
| | C++98 came before C99, so who diverged from whom?
| |
| | It doesn't matter.
|
| Yet, you're you were construeing it as an argument to support your
Joseph S. Myers said:
On Fri, 16 Sep 2005, Zack Weinberg wrote:
I am with Joe Buck in the opinion that even a 1% performance penalty for
implementing (A) [or (B)] would be too much -- I suggest this be fixed by
convincing the C++ committee to allow (C) and not just by phase 1
transformations,
Gabriel Dos Reis said:
Zack Weinberg [EMAIL PROTECTED] writes:
| When the standard is arguably buggy -- if nothing else, it diverges from C
C++98 came before C99, so who diverged from whom?
It doesn't matter. The divergence should be resolved in favor of whichever
standard has it right, not
Zack Weinberg [EMAIL PROTECTED] writes:
| Gabriel Dos Reis said:
| Zack Weinberg [EMAIL PROTECTED] writes:
| | When the standard is arguably buggy -- if nothing else, it diverges from C
|
| C++98 came before C99, so who diverged from whom?
|
| It doesn't matter.
Yet, you're you were
Paul Eggert [EMAIL PROTECTED] writes:
Hi Paul,
I proposed to insert the following paragraph after XCU page 213 line
8366 (i.e, at the end of the INPUT FILES section of the c99 spec
http://www.opengroup.org/onlinepubs/009695399/utilities/c99.html):
It is implementation-defined whether
On Fri, 16 Sep 2005, Geoffrey Keating wrote:
What this means in practise, I think, is that the structure that
represents a token, 'struct cpp_token' will grow from 16 bytes to 20
bytes, which makes it 2 cache lines rather than 1, and a subsequent
memory use increase and compiler performance
On Fri, 16 Sep 2005, Geoffrey Keating wrote:
Adding salt to the wound, of course, is that for C the only difference
between an (A) or (B) and a (C) implementation is that a (C)
implementation is less expressive: there are some programs, all of
which are erroneous and require a diagnostic,
On 16/09/2005, at 5:12 AM, Joseph S. Myers wrote:
On Fri, 16 Sep 2005, Geoffrey Keating wrote:
What this means in practise, I think, is that the structure that
represents a token, 'struct cpp_token' will grow from 16 bytes to 20
bytes, which makes it 2 cache lines rather than 1, and a
Joe Buck [EMAIL PROTECTED] writes:
| To me, even a 1% performance hit to fix this would be excessive.
My opinion is that is an excessive statement.
-- Gaby
[I apologize for breaking the thread; I am currently stuck using a web-mail
client that does not permit manual insertion of References: headers. Please
don't take this comment as a sign that I am resuming participation in GCC
development in general.]
Joseph Myers:
There are plenty of spare bits
On Fri, Sep 16, 2005 at 08:58:12PM +0200, Gabriel Dos Reis wrote:
Joe Buck [EMAIL PROTECTED] writes:
| To me, even a 1% performance hit to fix this would be excessive.
My opinion is that is an excessive statement.
Really, Gaby? Consider that there are hundreds of other open bugs.
Would
Joe Buck [EMAIL PROTECTED] writes:
| On Fri, Sep 16, 2005 at 08:58:12PM +0200, Gabriel Dos Reis wrote:
| Joe Buck [EMAIL PROTECTED] writes:
|
| | To me, even a 1% performance hit to fix this would be excessive.
|
| My opinion is that is an excessive statement.
|
| Really, Gaby? Consider
Joe Buck writes:
To me, even a 1% performance hit to fix this would be excessive.
I think any performance hit to support UCNs or extended characters outside
of strings and comments is undesirable. GCC should have an option like
-trigraphs for the few programs that need this feature.
Thanks, everybody, for writing about this.
The standardization process is one of consensus, and if the GCC
developers find some areas of disagreement here I think it unlikely
that the other POSIX implementers will agree with the proposed action.
Hence I am thinking of weakening it.
Currently the
On Fri, 16 Sep 2005, Ross Ridge wrote:
Joe Buck writes:
To me, even a 1% performance hit to fix this would be excessive.
I think any performance hit to support UCNs or extended characters outside
of strings and comments is undesirable. GCC should have an option like
-trigraphs for the
On Fri, 16 Sep 2005, Zack Weinberg wrote:
Especially for C++ which constructs a cpp_token array (sort of) representing
the entire translation unit, it is desirable to make cpp_token *smaller* --
and it would be relatively easy to win back that 'whole word not used in the
case of identifiers',
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
Ross Ridge wrote:
Well, maybe I'm missing something, but it never converts input characters
to UCNs so that means it doesn't do (A) or (B), and the only thing it
converts to wide characters are wide string literals, so it doesn't do
(C).
You are thinking operationally, when you should think
On Wed, 14 Sep 2005, Paul Eggert wrote:
So my question is: Is it a burden on GCC to require interpretation (B)?
Yes, but my position remains that we *should* aim to implement (B) and
this is a proper burden to impose.
For how the interpretations can be distinguished, see bug 9449 comments 21
Ross Ridge wrote:
Well, maybe I'm missing something, but it never converts input characters
to UCNs so that means it doesn't do (A) or (B), and the only thing it
converts to wide characters are wide string literals, so it doesn't do
(C).
On Thu, Sep 15, 2005 at 07:24:47AM -0400, Robert Dewar
You are thinking operationally, when you should think semantically.
Remember that as-if applies here. The rules as stated give ways to
achieve certain effects, the question is not whether we are following
the operational rules, but whether we are following the effects.
Thinking semantically
Ross Ridge wrote:
Thinking semantically is irrelevent because the question isn't whether GCC
conforms to C99 or POSIX. It clearly doesn't. GCC fails the as-if rule.
The question is one of implementation burden, which can only be answered
by examining GCC's implementation.
Once again we are
I recently proposed to the Open Group an action that would modify the
POSIX specification for the c99 command that is often implemented
using GCC. I thought the action would not affect GCC's conformance,
but Joseph S. Myers raised the issue of UCNs and multibyte characters
and I'd like to
On Wed, Sep 14, 2005 at 01:50:19PM -0700, Paul Eggert wrote:
In response Joseph S. Myers pointed out that this action would require
c99 to use interpretation B of section 5.2.1 (page 20) of the C99 Rationale
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf.
The Rationale says C
Paul Eggert wrote:
So my question is: Is it a burden on GCC to require interpretation (B)?
My understanding is that GCC already uses (B), and that the answer is
no, it's no problem, but if I'm wrong please let me know.
GCC doesn't use (A), (B) or (C). GCC doesn't conform to C99 and
any
Ross Ridge wrote:
GCC doesn't use (A), (B) or (C). GCC doesn't conform to C99 and
any implementation of c99 that uses GCC would presumably also be
non-conforming.
Robert Dewar wrote:
What exactly is the observable non-conformance?
GCC doesn't claim C99 conformance. The following URL lists
[EMAIL PROTECTED] (Ross Ridge) writes:
Ross Ridge wrote:
GCC doesn't use (A), (B) or (C). GCC doesn't conform to C99 and
any implementation of c99 that uses GCC would presumably also be
non-conforming.
Robert Dewar wrote:
What exactly is the observable non-conformance?
GCC
Paul Eggert wrote:-
Here's the problem. Currently, POSIX places almost no requirements on
how c99 transforms the physical source file into C source-language
characters. For example, c99 is free to treat CR as LF, ignore
trailing white space, convert tabs to spaces, or even (perversely)
Ross Ridge wrote:
GCC doesn't use (A), (B) or (C). GCC doesn't conform to C99 and
any implementation of c99 that uses GCC would presumably also be
non-conforming.
Robert Dewar wrote:
What exactly is the observable non-conformance?
Ross Ridge wrote:
GCC doesn't claim C99 conformance. The
Ross Ridge wrote:
GCC doesn't claim C99 conformance. The following URL lists a number of
different areas in which GCC is known not to conform:
I was not asking the general question, I was asking how it fails
to conform wrt the particular technical issue at hand.
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.
[EMAIL PROTECTED] (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
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
43 matches
Mail list logo
