A simple parser

R

Richard

Richard Heathfield said:
Richard said:


I have already said that his article was topical, so my desires are
neither

Well, finally you have. It seemed on topic enough to most others.
here nor there. I have also already explained my meaning sufficiently
clearly, I think. See quoted text, above.

No. You said that it was his fault that you are unable to read/check his
code. "He missed a trick" to borrow your excuse. Well, he didn't miss
any trick. Because you are clearly unable or unwilling to check out C99
compliant code as you have repeatedly stated - and that is what his code
is - C99. So he missed no tricks at all.


--
 
Z

zebedee

Richard said:
I only have two - K&R C and C90 - and of the two I choose C90. (No surprise
there.)


Note that gcc, despite its std=c99 switch, is not a conforming C99 compiler.
Nor does it have a conforming C99 libc.

Note that gcc, despite its std=c89 switch, is not a conforming C90
compiler. Nor does it have a conforming C90 libc.

Your point?
 
R

Richard

zebedee said:
Note that gcc, despite its std=c89 switch, is not a conforming C90
compiler. Nor does it have a conforming C90 libc.

Your point?

The main point is that no one has claimed that gcc is a fully conforming
c99 compiler. I merely stated that it supports a useful subset.

I have a feeling that this is an argument which can not be won and it is
best to drop it.
 
R

Richard Heathfield

zebedee said:
Note that gcc, despite its std=c89 switch, is not a conforming C90
compiler. Nor does it have a conforming C90 libc.

Interesting. Can you support that claim? (I'm not saying you're wrong. And
I'm not saying you're right. I'm just curious.)
Your point?

Portability. Yours?
 
T

Tak-Shing Chan

Tak-Shing Chan said:
[snip]

Look, there are two camps here - the "let's make it work everywhere"
camp, and the "I wonder if I can make it work *here*" camp. Both are
legitimate positions, but I think the former better reflects the purpose
of comp.lang.c.

I believe that you are confusing portability with backward
compatibility.

Your beliefs about my intent are always amusing.

Pray tell, where did I say /anything/ about your intent?

You said that ``there are two camps here'', and that you
``think the former better reflects the purpose of comp.lang.c''.
I took this to mean that you belong to the first camp, and
commented on its flaws accordingly. Of course, it is possible
that you are neutral, but your previous posts on C99 have
disconfirmed this hypothesis.

Tak-Shing
 
B

Bob Martin

in 701475 20061016 094846 Richard said:
What you mean is, had he complied to your desires ...

Did you mean "complied with"? Must get these things right, mustn't we?
 
K

Keith Thompson

zebedee said:
Note that gcc, despite its std=c89 switch, is not a conforming C90
compiler.

If gcc is invoked with "-ansi" (or equivalently "-std=c89") and a few
other options, it's conforming as far as I know. More precisely, I'm
not aware of any conformance failures.

All software has bugs. I believe gcc is *intended* to be a conforming
C90 compiler. If there are any major areas in which it fails to
conform to C90, I'd be intererested in hearing about them.
Nor does it have a conforming C90 libc.

gcc doesn't have a libc at all, conforming or otherwise. (gcc and
glibc are two separate things; gcc uses other libraries on systems
that don't have glibc.)

If you're claiming that glibc is non-conforming, I'd also be
interested in hearing about any major problems.
 
B

Bill Pursell

Richard said:
/* Multi-line comments
Are easier and faster
Using old syntax. */

// BCPL style
// Necessitates rather more
// Typing of line noise

The BCPL style comment took longer to type, and used up two more bytes of
horizontal space (text not included, obviously), and was slightly harder to
manage than the C style comment.

Stylistically, it is preferred (which is to say preferred by me) to
write:

/*
* Multi-line comments
* are easier and faster
* using old syntax.
*/

In which case, the /**/ syntax requires more space, and takes
longer to type (assuming that " *" is slower than '//', which would
need to be tested. Being 2 different keys makes it faster, but
the timing for the modifier key requires a degree of manual
dexterity that may slow you down more.)

However, neither of those points are relevant. The ability to
insert a comment quickly is, IMO, a *bad* thing. Comments
require thought and time, and if one doesn't have the time to
type 2 characters at the end of the comment, then one
should not be modifying the text of the program in any way.

The only real reason to avoid the use of //-style comments
is aesthetics. Namely, they are repulsive. Obviously,
there is no objective sense in which they are ugly, and
I certainly won't claim that, but they do make me cringe.
 
Z

zebedee

Keith said:
If gcc is invoked with "-ansi" (or equivalently "-std=c89") and a few
other options, it's conforming as far as I know. More precisely, I'm
not aware of any conformance failures.

All software has bugs. I believe gcc is *intended* to be a conforming
C90 compiler. If there are any major areas in which it fails to
conform to C90, I'd be intererested in hearing about them.

There are many code snippets I could give where GCC fails compile-time
conformance (never mind run-time). Compile time is my personal area
of interest, as I'm writing a C front end of my own. I have worked on
GCC in the past; it is curious that so many people believe it is
conforming, though I admit it's pretty good.

Most could be fixed with small changes in GCC, i.e. they can be
considered bugs or oversights. One class is harder to fix (and shared
by the EDG front end; it's in GCC's bug database :cool:. The area where
GCC has the most difficulty, and is least easily fixed, is in expression
handling, particularly constant expressions and folding. These will
not, to the best of my knowledge, be fixed any time soon.

As I said I could, but won't, provide many snippets. One is sufficient
to prove my claim, so note that GCC fails to diagnose the constraint
violation in the following translation unit:

int n = 0, p[n * 0 + 1];
 
J

jacob navia

zebedee said:
As I said I could, but won't, provide many snippets. One is sufficient
to prove my claim, so note that GCC fails to diagnose the constraint
violation in the following translation unit:

int n = 0, p[n * 0 + 1];

If you write:

int n = 0,p[n * 100 + 1];

THEN
gcc complains.

If you write:

int n = 10, p[n * 0 + 1];

it doesn't complain.

The problem then is tha gccc assumes that any number
multiplied by zero is zero.

Wrong assumption???

I do not think so.

And I can really understand the gcc developers that do not
fill like working (for free) to satisfy this kind of "problems".

This will (provably) never lead to any run time problem.

jacob

P.S. To say that because of this feature gcc is not compliant is
widely exaggerated.
 
G

Guest

jacob said:
zebedee said:
As I said I could, but won't, provide many snippets. One is sufficient
to prove my claim, so note that GCC fails to diagnose the constraint
violation in the following translation unit:

int n = 0, p[n * 0 + 1];
[...]
P.S. To say that because of this feature gcc is not compliant is
widely exaggerated.

How would you classify not issuing a mandatory diagnostic, then? Why is
this diagnostic less important than others? Or can an implementation
never issue any diagnostic at all, yet claim conformance?

(Note: I have not checked that GCC really has this problem.)
 
Z

zebedee

jacob said:
If you write:

int n = 0,p[n * 100 + 1];

THEN
gcc complains.

If you write:

int n = 10, p[n * 0 + 1];

it doesn't complain.

The problem then is tha gccc assumes that any number
multiplied by zero is zero.

I'm well aware of the cause of the problem, thanks. So are
the GCC developers (of whom I used to be one). GCC (constant)
folds too aggressively; this is and has been the cause of countless
bugs. The developers rightly consider this a problem that should be
fixed, they just haven't found the time to do it yet. Part of
the reason is that fixing it is very hard with GCC's current
design.

The best solution is to diagnose the "n" the moment the parser
sees it, of course. GCC in general diagnoses things later
than it could, and has frequently manipulated its internal
representation in the meantime to a different form, as here.
Wrong assumption???

I do not think so.

And I can really understand the gcc developers that do not
fill like working (for free) to satisfy this kind of "problems".

This will (provably) never lead to any run time problem.

See above, I never claimed it was a problem. I simply claimed
it wasn't conforming, which is easily shown.

The freely available version of LCC (4.1) I have access to fails
to compile the following strictly conforming translation unit
(amongst others). Have you fixed this in LCC-Win32? Perhaps
this also isn't worth fixing? :cool:

int f (e)
int e[sizeof (enum e { e1 = 3 })];
{
return e[e1];
}
 
G

Guest

zebedee said:
The freely available version of LCC (4.1) I have access to fails
to compile the following strictly conforming translation unit
(amongst others). Have you fixed this in LCC-Win32? Perhaps
this also isn't worth fixing? :cool:

int f (e)
int e[sizeof (enum e { e1 = 3 })];
{
return e[e1];
}

Are you sure that's strictly conforming?
From n1124 6.9.1p6:
"If the declarator includes an identifier list, each declaration in the
declaration list shall have at least one declarator, those declarators
shall declare only identifiers from the identifier list, and every
identifier in the identifier list shall be declared."

"e[sizeof (enum e { e1 = 3 })]" is a declarator, and declares two
identifiers not in the identifier list, does it not?
 
Z

zebedee

Harald said:
zebedee said:
The freely available version of LCC (4.1) I have access to fails
to compile the following strictly conforming translation unit
(amongst others). Have you fixed this in LCC-Win32? Perhaps
this also isn't worth fixing? :cool:

int f (e)
int e[sizeof (enum e { e1 = 3 })];
{
return e[e1];
}

Are you sure that's strictly conforming?
From n1124 6.9.1p6:
"If the declarator includes an identifier list, each declaration in the
declaration list shall have at least one declarator, those declarators
shall declare only identifiers from the identifier list, and every
identifier in the identifier list shall be declared."

"e[sizeof (enum e { e1 = 3 })]" is a declarator, and declares two
identifiers not in the identifier list, does it not?

Hehe, you're right, which makes several other compilers not conforming
in this respect :cool: I suspect the paragraph in question was not
intended to apply to those identifiers, but I could be wrong.

To my chagrin, I should probably fix my testsuite.
 
J

jacob navia

zebedee said:
Harald said:
zebedee said:
The freely available version of LCC (4.1) I have access to fails
to compile the following strictly conforming translation unit
(amongst others). Have you fixed this in LCC-Win32? Perhaps
this also isn't worth fixing? :cool:

int f (e)
int e[sizeof (enum e { e1 = 3 })];
{
return e[e1];
}


Are you sure that's strictly conforming?
From n1124 6.9.1p6:

"If the declarator includes an identifier list, each declaration in the
declaration list shall have at least one declarator, those declarators
shall declare only identifiers from the identifier list, and every
identifier in the identifier list shall be declared."

"e[sizeof (enum e { e1 = 3 })]" is a declarator, and declares two
identifiers not in the identifier list, does it not?


Hehe, you're right, which makes several other compilers not conforming
in this respect :cool: I suspect the paragraph in question was not
intended to apply to those identifiers, but I could be wrong.

To my chagrin, I should probably fix my testsuite.

Error tb.c: 2 declared parameter 'e1' is missing

Phew !!!!

:)

jacob
 
R

Richard Heathfield

zebedee said:

As I said I could, but won't, provide many snippets. One is sufficient
to prove my claim, so note that GCC fails to diagnose the constraint
violation in the following translation unit:

int n = 0, p[n * 0 + 1];

Thank you very much. Now that I know gcc doesn't diagnose this constraint
violation, I shall make a special effort to avoid violating this
constraint! :)

Do you have any examples where strictly conforming C90 code is translated
incorrectly by gcc-in-C90-conforming-mode?
 
J

jacob navia

Richard said:
zebedee said:

As I said I could, but won't, provide many snippets. One is sufficient
to prove my claim, so note that GCC fails to diagnose the constraint
violation in the following translation unit:

int n = 0, p[n * 0 + 1];


Thank you very much. Now that I know gcc doesn't diagnose this constraint
violation, I shall make a special effort to avoid violating this
constraint! :)

Do you have any examples where strictly conforming C90 code is translated
incorrectly by gcc-in-C90-conforming-mode?
Bugs in gcc?

Well if you want bugs just use gcc-3.1.1 with -O3 in amd64 (64 bit
mode).

You will find plenty, it is one of the latest back-ends to gcc.
 
G

Guest

Richard said:
zebedee said:

As I said I could, but won't, provide many snippets. One is sufficient
to prove my claim, so note that GCC fails to diagnose the constraint
violation in the following translation unit:

int n = 0, p[n * 0 + 1];

Thank you very much. Now that I know gcc doesn't diagnose this constraint
violation, I shall make a special effort to avoid violating this
constraint! :)

Do you have any examples where strictly conforming C90 code is translated
incorrectly by gcc-in-C90-conforming-mode?

GCC's bug database is easily available. :) Check out
http://gcc.gnu.org/PR27184. If you would also like an example of
strictly conforming C90 code being rejected, see
http://gcc.gnu.org/PR19977.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

How to remove // comments 100
// comments 35
Text processing 29
Serial port 5
Command Line Arguments 0
Deleting first N lines from a text file 26
Working with files 1
Taking a stab at getline 40

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top