A simple parser

[Keith Thompson]

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.

Then we disagree on whether that's a "major area". To be precise,
constant expressions are certainly a major area of C, but I believe
that gcc works correctly with *most* constant expressions. There are
bugs, of course.

 

[Richard Heathfield]

Mark McIntyre said:

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.

I don't know where you're getting that from. My responses in this thread
have been consistent with pretty well all my responses in this newsgroup
over the last seven years or so. I'm sick and tired of Tak-Shing's
fine-toothed thread-stretcher bickering over non-C-related minutiae, and I
figured that an argument about the meaning of "intent" could only head in
the same direction, which is why I dismissed it so off-handedly.

Welcome to my killfile.

<shrug> What you read is your decision. What I say is mine.

 

[Richard Heathfield]

Mark McIntyre said:

This is false and you know it.

If I knew it to be false, I would not have claimed it to be true. Not only
do I not know it to be false, but I believe it to be true. Keith Thompson
has already given the reason, so I won't repeat it here.

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

I'm using the gcc that ships with the OS I'm using. It's a working system,
which I'm reluctant to change for as long as it suits my needs. I'm not
interested in whether other people consider it obsolete, but only in
whether it does what I need it to do from a conformance perspective. It
does, and that's what matters.

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

It is not wise to insult people merely for disagreeing with you.

 

[Richard Heathfield]

Mark McIntyre said:

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

C90 offers much better coverage than K&R C. When C99 offers wider coverage
than C90, nobody will be more pleased than I (if only because it means
these silly little discussions will end at last).

[...] you're being a fool.

For disagreeing with you? I Don't Think So (tm).

 

[Richard Heathfield]

Harald van D?k said:

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

What makes you think the code is never executed? The code is merely a single
translation unit. The implementation cannot know whether the code will be
executed. It can certainly tell that the initialisation will result in
integer overflow, however, and it is perfectly within its rights to
diagnose this.

 

[Richard Heathfield]

Mark McIntyre said:

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 *have* looked at the whole C99 issue dispassionately. Otherwise, I
wouldn't bother "fighting" about it.

I strongly suggest you step back and take stock.

I took stock already. All present and correct. You?

 

[Keith Thompson]

Harald van D?k said:

What makes you think the code is never executed? The code is merely a single
translation unit. The implementation cannot know whether the code will be
executed. It can certainly tell that the initialisation will result in
integer overflow, however, and it is perfectly within its rights to
diagnose this.

Of course, but it's not within its rights to fail to translate it (in
a conforming mode).

 

[Richard Heathfield]

Mark McIntyre said:

Thats fine. But if you plan to do that, you need to accept that C99 is
around,
Where?

that people use its features, and that you can't play Canute
and insist they stop.

On the contrary, I'll be delighted when they can start.

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.

No, I don't *have* to do that at all. If I use a compiler that supports a
reasonable non-C90 subset of C99 and take advantage of the features
thereof, my code is suddenly not portable to any compiler that uses some
other reasonable non-C90 subset of C99 that does not wholly encompass my
compiler's reasonable non-C90 subset. Is this not blindingly obvious?

And is this not a sufficiently dangerous danger that it should be pointed
out to those who use C99isms? After all, we quite often warn people against
much less likely dangers.

Frankly ts stupid
and arrogant of you, not to say a bloody waste of bandwidth, to deny
the existence of C89.

I have never done so as far as I am aware. I fully agree that C89 exists. I
will even go so far as to agree that C99 exists. The existence of one, or
two, or even six (ish) implementations is not sufficient, however, and to
call people stupid and arrogant for pointing out the facts is ill-advised.

 

[Richard Heathfield]

Mark McIntyre said:

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

Are we? I'm not. Which leaves you talking to whom, about what, exactly?

<snip>

 

[Richard Heathfield]

Keith Thompson said:

Of course, but it's not within its rights to fail to translate it (in
a conforming mode).

C&V, please. I know of no requirement on implementations to translate *any*
program (except the one that has a brazillion nested foobars in it, of
course), let alone one that is manifestly incorrect.

 

[Keith Thompson]

Mark McIntyre said:

I *have* looked at the whole C99 issue dispassionately. Otherwise, I
wouldn't bother "fighting" about it.

I suggest that this isn't just about the C99 issue.

I took stock already. All present and correct. You?

Without reference to Mark's recent postings in this thread, let me
explain why I personally had a bit of a problem with your followup
near the beginning of this brouhaha. I'll probably drop the subject
after this, unless you care to discuss it further.

jacob navia posted a chunk of code. It was, as far as I can tell,
valid C99. It was, as far as I can tell, valid C90 with the exception
of its use of "//" comments and of mixed declarations and statements.

Your response was to post the error messages produced by your compiler
(gcc 2.whatever in C90 conforming mode).

In my opinion, it should have been obvious to you that the code wasn't
intended to be C90, and that it was probably intended to be valid C99.
C99 code is clearly topical in this newsgroup, and would be even if
there were *no* conforming C99 compilers, or even if no compilers
implemented any C99 features (other than the ones already in C90).

You demonstrated that a conforming C90 compiler becomes confused when
confronted with "//" comments (unless it specifically recognizes them
for the purpose of diagnosing them, which yours doesn't). This is, I
believe, well known and not particularly interesting.

You acted like someone who doesn't even know about "//" comments,
which I'm certain is not the case.

You could have pointed out that "//" comments are ill-advised in
Usenet articles, and that mixing declarations and statements makes the
code less portable than it could be; that would have been a
contribution to the discussion. You knew, or should have known, the
actual issue with the code, but rather than saying so, you posted
something that appeared to be mere snark. Whether you intended it
that way is another question. Whether you were influenced by the
identity of the previous poster is yet another question, one on which
I will not speculate out loud.

(And a series of overreactions led to a fairly pointless flame war,
but I'm not commenting on that.)

Your contributions to this newsgroup over the years have been
invaluable, more than enough, IMHO, to earn you a pass for the
occasional lapse.

 

[Keith Thompson]

Keith Thompson said:

C&V, please. I know of no requirement on implementations to translate *any*
program (except the one that has a brazillion nested foobars in it, of
course), let alone one that is manifestly incorrect.

Sure, any program other than the "one instance of every one of the
following" cited in the translation limits clause of the standard,
could hit some translation limit and therefore fail to compile.

Here's the code fragment from PR19977:
================================
#include <limits.h>

void
f (void)
{
int c = INT_MAX + 1;
}
================================

Let's embed this in a complete program:
================================
#include <limits.h>

void f(void)
{
int c = INT_MAX + 1;
}

int main(void)
{
return 0;
}
================================

I believe this program is strictly conforming.

 

[Richard Heathfield]

Keith Thompson said:

Without reference to Mark's recent postings in this thread, let me
explain why I personally had a bit of a problem with your followup
near the beginning of this brouhaha. I'll probably drop the subject
after this, unless you care to discuss it further.

Probably not. I think we're probably both sick of it already, aren't we?

jacob navia posted a chunk of code. It was, as far as I can tell,
valid C99. It was, as far as I can tell, valid C90 with the exception
of its use of "//" comments and of mixed declarations and statements.

That's quite an "except", but okay, I believe you.

Your response was to post the error messages produced by your compiler
(gcc 2.whatever in C90 conforming mode).

Right. The message being "my C90 compiler doesn't like this code". And I
don't suppose yours does, either.

In my opinion, it should have been obvious to you that the code wasn't
intended to be C90,

It was obvious to my compiler, at any rate.

and that it was probably intended to be valid C99.

Fine. When the world and his dog get a C compiler, the code will become
relevant, at which point I'll take a closer look.

C99 code is clearly topical in this newsgroup,

Undoubtedly. I am not disputing the topicality of the OP's code.

Your contributions to this newsgroup over the years have been
invaluable, more than enough, IMHO, to earn you a pass for the
occasional lapse.

Thanks for the compliment, but I'm still not convinced that this /is/ a
lapse. If you examine my contributions to this newsgroup over the years,
you will find that I generally admit it when I'm wrong. If I could see how
I were in the wrong here, fine - but try as I might, I can't see what's
wrong with pointing out the non-portability of code posted on the
comp.lang.c newsgroup. You've done it yourself, dozens if not hundreds of
times.

???

 

[Richard Heathfield]

Keith Thompson said:

Here's the code fragment from PR19977:

#include <limits.h>

void f(void)
{
int c = INT_MAX + 1;
}

int main(void)
{
return 0;
}
================================

I believe this program is strictly conforming.

I'm not sure about that. I've never been very convinced by these "this bit
is never called, so it doesn't count" arguments. But what I /am/ sure about
is that either - as in your harness, for example - f() is never called, in
which case it's dead code which should be removed, or it *is* called, in
which case it's broken code which should be fixed. Either way, if gcc
swears at it, that's a Good Thing, IMHO, and certainly no barrier to
portability. If you want it to compile under gcc, fix the integer overflow
problem.

Or, of course, you could simply use the version of gcc I use, which compiles
the code, your harness and all, just fine (although it does issue a
diagnostic message, which it is within its rights to do).

Bug? What bug?

 

[Keith Thompson]

Thanks for the compliment, but I'm still not convinced that this /is/ a
lapse. If you examine my contributions to this newsgroup over the years,
you will find that I generally admit it when I'm wrong. If I could see how
I were in the wrong here, fine - but try as I might, I can't see what's
wrong with pointing out the non-portability of code posted on the
comp.lang.c newsgroup. You've done it yourself, dozens if not hundreds of
times.

Yes, but when I point out that a piece of code is non-portable, I
explain *why* (and, usually, so do you).

You didn't point out that the code was non-portable. You posted a
bunch of compiler error messages, implying that the code was full of
syntax errors (which it really *wasn't*), and you made no further
comment at all. Your reply, taken by itself, was indistinguishable
from one from someone who had never heard of "//" comments at all,
didn't recognize them in the posted source code, and honestly thought
they were nothing more than syntax errors. Perhaps you were playing
dumb to make a point; if so, the point didn't come across very well in
this case.

Your response was, as in the old Microsoft joke about the hot air
balloon, technically currect but not useful.

 

[Richard Heathfield]

Keith Thompson said:

Your response was, as in the old Microsoft joke about the hot air
balloon, technically currect but not useful.

It was IBM when I heard it. Plus ca change, plus ca meme chose.

 

[Guest]

Keith Thompson said:





I'm not sure about that. I've never been very convinced by these "this bit
is never called, so it doesn't count" arguments.
http://open-std.org/JTC1/SC22/WG14/www/docs/dr_109.html

But what I /am/ sure about
is that either - as in your harness, for example - f() is never called, in
which case it's dead code which should be removed, or it *is* called, in
which case it's broken code which should be fixed. Either way, if gcc
swears at it, that's a Good Thing, IMHO, and certainly no barrier to
portability. If you want it to compile under gcc, fix the integer overflow
problem.

Or, of course, you could simply use the version of gcc I use, which compiles
the code, your harness and all, just fine (although it does issue a
diagnostic message, which it is within its rights to do).

Bug? What bug?

To be sure, did you use both the -ansi and -pedantic-errors options?
Versions as old as 3.2.3 are listed in the "known to fail" list for
that bug. If your version is older and accepts it, fair enough. If it
doesn't, the fact that other "intended to be conforming" modes are
available is not really relevant, unless you don't consider problems
that are only exposed with optimisations enabled as bugs either.

 

[Guest]

To be sure, did you use both the -ansi and -pedantic-errors options?
Versions as old as 3.2.3 are listed in the "known to fail" list for

That should be "as old as 2.95.3", of course, sorry.

 

[Richard Heathfield]

Harald van D?k said:

http://open-std.org/JTC1/SC22/WG14/www/docs/dr_109.html

Fair enough. I'm still not *very* convinced, but I'm a lot more convinced
than I was.

If your version is older and accepts it, fair enough.

It is, and it does.

 

[Frederick Gotham]

Richard Heathfield posted:

It is not wise to insult people merely for disagreeing with you.

Mark McIntyre is an thorough-bred asshole, plain and simple. I've yet to hear
him utter one pleasant syllable.