A simple parser

[Keith Thompson]

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 . 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];

Ok, there's a bug. As I wrote above, all software has bugs.
<http://gcc.gnu.org/bugzilla/> shows 3803 open bugs; I don't know what
proportion of those are related to C90 standard conformance.

Strictly speaking, any compiler with a bug is not a conforming
compiler. By that criterion, I doubt that there has ever been a
conforming compiler for any language.

But that's not what I asked about. I asked if there are any *major
areas* in which gcc fails to conform to C90.

There are clearly areas in which gcc fails to conform to C99;
<http://gcc.gnu.org/c99status.html> is a summary of the current
status. Is there, or should there be, a similar table for C90?

 

[Richard Heathfield]

Harald van D?k said:

GCC's bug database is easily available. Check out
http://gcc.gnu.org/PR27184.

Hardly strictly conforming...

If you would also like an example of

strictly conforming C90 code being rejected, see
http://gcc.gnu.org/PR19977.

What's "strictly conforming" about integer overflow?

 

[Christopher Benson-Manica]

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

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

If that is your preferred means of writing multi-line comments, would
you not write

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

?

The // syntax wins the space war by, well, exactly one character.
Hardly to be written home about. Not to mention that when commenting
blocks of code that may later be uncommented, the /**/ syntax wins hands
down.

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.

When one uses an editor capable of syntax highlighting they become
quite onobtrusive. In plain text, the situation is markedly
different and I agree completely.

 

[Guest]

Harald van D?k said:


Hardly strictly conforming...

If you would also like an example of

What's "strictly conforming" about integer overflow?

There is no integer overflow, since the code is never executed. This is
allowed in strictly conforming programs.

 

[Keith Thompson]

Ok, there's a bug. As I wrote above, all software has bugs.

That's probably not *quite* true. I'm sure there are bug-free programs.
I doubt that any of them are as complex as a compiler.

[...]

Strictly speaking, any compiler with a bug is not a conforming
compiler. By that criterion, I doubt that there has ever been a
conforming compiler for any language.

Unless the compiler, bugs^H^H^H^H misfeatures and all, serves as the
definition of the language. Of course, that's not the case for C.

 

[Mark McIntyre]

Mark McIntyre said:

Hmm? Does that mean you /do/ have a C99 conforming compiler? Fabulous - let
us know how it goes.

I've already suggested you stop being childish. Its quite
disappointing to see you persisting.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

No. Did you spot something in the code that *needed* a C99 feature, a

Lets not wander off track here. We're talking about whether /you/
found something that wasn't conforming.

feature so vital that it justified making the code non-C90-conforming?

What the above means is "I'm cross because people are criticizing
parts of my attack on jacob, so I propose to force the other guy into
a negative position so I can feel I'm right.".

Sorry, but you made an childish remark regarding nonexistent bugs in
some code, and you need to stop digging. You disingenuously ignored
the well-known cause of the warnings your obsolete compiler emitted,
and attempted to cast blame onto the writer. Very often that person is
in the wrong, and I'm right alongside you there with my tar and
feathers in such cases. This time, I'm shaking my head disappointedly.
You seriously weaken your case and credibility by such actions.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

When I invoke my gcc implementation in conforming mode it (correctly)
diagnoses single-line comments, mixed code/decls, etc.

Because you have a obsolete version of gcc. We've been through this.
Stop being disingenuous.

If you are asking me to turn off conforming mode, the answer is "No".

We're simply pointing out that your tests are invalid, just as much as
they'd be invalid if you used a pre-ANSI compiler.


--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Richard said:


In order to get gcc to support those features, one must invoke it in a
non-conforming mode.

This is false and you know it.

In order to get an obsolete version of gcc to support those features,
you have to turn off C90 compatibility. Whoopy doo.

Stop this Richard, you're making a tit of yourself.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

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.)

You can do your own web search I think.

Portability.

Portability? Then stick to pre-ANSI, there's still some compilers
around that require it.

Yours?

That you're being a fool.


--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

my first reaction (to an article asking for code crits) is to run the code
through a compiler - and I might not even read it first, especially if it's
long. The resulting compiler diagnostics give me a place to start the crit.

Thats fine. But if you plan to do that, you need to accept that C99 is
around, that people use its features, and that you can't play Canute
and insist they stop. Therefore you have to eliminate C99/C89 issues
from your response, either by manually tuning them out or by using a
compiler that supports a reasonable subset of C99. Frankly ts stupid
and arrogant of you, not to say a bloody waste of bandwidth, to deny
the existence of C89.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Keith Thompson said:

I remain to be convinced that it was a mistake.

Thats obvious, but frankly, thats part of the problem - that you're
not prepared to step away from the fight and look at the issue
dispassionately.

I strongly suggest you step back and take stock.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Keith Thompson said:

<snip>

gratuitous snip of the actual point of the post. You're behaving like
a very stupid person.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Tak-Shing Chan said:


Whatever.

You know what? I've had enough of you. You've behaved atrociously in
this thread, childish and bullying by turns, rude and petty and silly.
Welcome to my killfile.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

Richard said: [..]

Err, for the C99 features I use (primarily localised declarations),
gcc. I thought I mentioned that?

In order to get gcc to support those features, one must invoke it in a
non-conforming mode.

This is false and you know it.

No, he's right on this point.

gcc has a mode in which it's reasonably (but not perfectly) conforming
to C90. It has no mode in which it's as conforming to C99.

gcc supports "//" comments and mixed declarations and statements
either as gcc-specific extensions, or as part of its incomplete C99
support. The only way to get gcc to accept those features
(non-standard in C90, standard in C99) is to invoke it in a mode that
does not conform to any standard. Such a mode causes it to accept
*other* extensions as well; in other words, it will then fail to
diagnose a number of non-C90 constructs.

If gcc allowed you to accept "//" comments and mixed declarations and
statements while still rejecting all other non-C90 extensions, it
might be a different story. If there were a list of C99 features that
are supported by all current C compilers (a least common denominator
bigger than strict C90 but smaller than full C99), *and* a way to
invoke gcc so that it accepts those features and no others, then it
might be possible to write portable code that uses some of C99. But,
as far as I know, gcc's command-line options do not allow that kind of
fine-grained control.

Many (most?) other C compilers also support some C99 features, but not
necessarily the same set that gcc supports. If I compile my code with
gcc, using a mode in which it accepts "//" comments, it will fail to
diagnose accidental use of C99 features that might not be supported by
some other compiler. The *only* reliable way to guarantee maximal
portability is to invoke gcc is strict C90-conforming mode; any code
that passes that (barring compiler bugs) should be portable to any
C90-conforming implementation. (Well, that's not *quite* true; I
don't think gcc will complain about "int i = 33000;".)

Is there a table somewhere showing exactly which C99 features are
supported by which implementations? I know that such a list exists
for gcc, but a table for multiple implementations could give us a
better idea of what's really portable. And if such a table existed
and were generally known, it just might advance the goal of C99
conformance across the board.

 

[Keith Thompson]

You know what? I've had enough of you. You've behaved atrociously in
this thread, childish and bullying by turns, rude and petty and silly.
Welcome to my killfile.

That's entirely up to you, of course, but you might consider just
killing this thread and moving on. Richard has made, and continues to
make, a great contribution to this newsgroup. If you killfile him
over his behavior in this one thread, it will be, in my opinion, your
loss.

 

[zebedee]

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 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 !!!!

Rereading, I'm inclined back to my original reading. "those
declarators" I pretty clearly doesn't cover e1 here - e1
is not declared in the "declaration-list", it's declared in an
expression embedded in such a declaration.

e1 definitely isn't a declared as a parameter.

 

[zebedee]

But that's not what I asked about. I asked if there are any *major
areas* in which gcc fails to conform to C90.

I answered - the whole area of constant expressions. It's probably
the hardest part of the standard to get right and definitely the
weakest area of most compilers. I think only EDG gets it right.

 

[Mark McIntyre]

Richard said: [..]
Err, for the C99 features I use (primarily localised declarations),
gcc. I thought I mentioned that?

In order to get gcc to support those features, one must invoke it in a
non-conforming mode.

This is false and you know it.

No, he's right on this point.

No he's not.

gcc has a mode in which it's reasonably (but not perfectly) conforming
to C90. It has no mode in which it's as conforming to C99.

I disagree, but unlike RJH I have no intention of wasting my time
prolonging this thread further.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

If you killfile him
over his behavior in this one thread, it will be, in my opinion, your
loss.

Indeed it is, but I have begun to plonk for stupidity and rudeness,
rather than inaccuracy, hence he falls into the bucket whereas jacob
doesn't (yet) as he's inaccurate more than he's rude and so I feel he
needs to be corrected. Richard is currently stupid and rude more than
he's inaccurate, and so he fits the bill.... :-(

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan