468,463 Members | 1,978 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,463 developers. It's quick & easy.

A simple parser

Hi guys

I have written this small parser to print out the functions defined in a
C file. This is an example of parsing in C, that I want to add to my
tutorial. Comments (and bug reports) are welcome.

-------------------------------------------------------------cut here

/* A simple scanner that will take a file of C source code and
print the names of all functions therein, in the following format:
"Function XXXX found line dddd .... ddddd"
Algorithm. It scans for a terminating parentheses and an immediately
following opening brace. Comments can appear between the closing
paren and the opening braces, but no other characters besides white
space. Functions must have the correct prototype, K & R syntax
is not supported.
*/
#include <stdio.h>
#define MAXID 1024 // Longest Identifier we support. Sorry
// Java guys...
static char IdBuffer[MAXID]; // Buffer for remembering the function name
static int line = 1; // We start at line 1

// This function reads a character and if
// it is \n it bumps the line counter
static int Fgetc(FILE *f)
{
int c = fgetc(f);
if (c == '\n')
line++;
return c;
}

// Return 1 if the character is a legal C identifier
// character, zero if not. The parameter "start"
// means if an identifier START character
// (numbers) is desired.
static int IsIdentifier(int c,int start)
{
if (c >= 'a' && c <= 'z')
return 1;
if (c >= 'A' && c <= 'Z')
return 1;
if (start == 0 && c >= '0' && c <= '9')
return 1;
if (c == '_')
return 1;
return 0;
}

// Just prints the function name
static int PrintFunction(FILE *f)
{
printf("Function %s found line %d ...",IdBuffer,line);
return Fgetc(f);
}

// Reads a global identifier into our name buffer
static int ReadId(char c,FILE *f)
{
int i = 1;
IdBuffer[0] = c;
while (i < MAXID-1) {
c = Fgetc(f);
if (c != EOF) {
if (IsIdentifier(c,0))
IdBuffer[i++] = c;
else break;
}
else break;
}
IdBuffer[i] = 0;
return c;
}
static int ParseString(FILE *f) // Skips strings
{
int c = Fgetc(f);
while (c != EOF && c != '"') {
if (c == '\\')
c = Fgetc(f);
if (c != EOF)
c = Fgetc(f);
}
if (c == '"')
c = Fgetc(f);
return c;
}

static int ParseComment(FILE *f) // Skips comments
{
int c = Fgetc(f);
restart:
while (c != '*') {
c = Fgetc(f);
if (c == EOF)
return EOF;
}
c = Fgetc(f);
if (c == '/')
return Fgetc(f);
else goto restart;
}
static int ParseCppComment(FILE *f) // Skips // comments
{
int c = Fgetc(f);
while (c != EOF && c != '\n') {
if (c == '\\')
c = Fgetc(f);
if (c != EOF)
c = Fgetc(f);
}
if (c == '\n')
c = Fgetc(f);
return c;
}

// Skips white space and comments
static int SkipWhiteSpace(int c,FILE *f) {
if (c ' ')
return c;
while (c <= ' ') {
c = Fgetc(f);
if (c == '/') {
c = Fgetc(f);
if (c == '*')
c = ParseComment(f);
else if (c == '/')
c = ParseCppComment(f);
}
}
return c;
}

// Skips chars between simple quotes
static int ParseQuotedChar(FILE *f)
{
int c = Fgetc(f);
while (c != EOF && c != '\'') {
if (c == '\\')
c = Fgetc(f);
if (c != EOF)
c = Fgetc(f);
}
if (c == '\'')
c = Fgetc(f);
return c;
}
int main(int argc,char *argv[])
{
if (argc == 1) {
printf("Usage: %s <file.c>\n",argv[0]);
return 1;
}
FILE *f = fopen(argv[1],"r");
if (f == NULL) {
printf("Can't find %s\n",argv[1]);
return 2;
}
int c = Fgetc(f);
int level = 0;
int parenlevel = 0;
int inFunction = 0;
while (c != EOF) {
// Note that each of the switches must advance the
// character read so that we avoid an infinite loop.
switch (c) {
case '"':
c = ParseString(f);
break;
case '/':
c = Fgetc(f);
if (c == '*')
c = ParseComment(f);
else if (c == '/')
c = ParseCppComment(f);
break;
case '\'':
c = ParseQuotedChar(f);
break;
case '{':
level++;
c = Fgetc(f);
break;
case '}':
if (level == 1 && inFunction) {
printf(" %d\n",line);
inFunction = 0;
}
if (level 0)
level--;
c = Fgetc(f);
break;
case '(':
parenlevel++;
c = Fgetc(f);
break;
case ')':
if (parenlevel 0)
parenlevel--;
c = Fgetc(f);
if ((parenlevel|level) == 0) {
c = SkipWhiteSpace(c,f);
if (c == '{') {
level++;
inFunction = 1;
c = PrintFunction(f);
}
}
break;
default:
if ((level | parenlevel) == 0 &&
IsIdentifier(c,1))
c = ReadId(c,f);
else c = Fgetc(f);
}
}
fclose(f);
return 0;
}
Oct 14 '06
121 5393
zebedee <ze*****@zebedee.netwrites:
Keith Thompson wrote:
>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.
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Oct 17 '06 #101
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.
<shrugWhat you read is your decision. What I say is mine.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #102
Mark McIntyre said:
On Sun, 15 Oct 2006 23:36:08 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>>Richard said:
>>Richard Heathfield <in*****@invalid.invalidwrites:
Yes, but where are the compilers?
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.
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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #103
Mark McIntyre said:

<snip>
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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #104
Harald van D?k said:
Richard Heathfield wrote:
>Harald van D?k said:
> 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?

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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #105
Mark McIntyre said:
On Mon, 16 Oct 2006 02:01:57 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>>Keith Thompson said:
>>>
Which explains your mistake, sir.

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 *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?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #106
Mark McIntyre said:
On Sun, 15 Oct 2006 22:49:22 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>>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,
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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #107
Richard Heathfield <in*****@invalid.invalidwrites:
Harald van D?k said:
>Richard Heathfield wrote:
>>Harald van D?k said:
>> 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?

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.
Of course, but it's not within its rights to fail to translate it (in
a conforming mode).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Oct 18 '06 #108
Mark McIntyre said:
On Sun, 15 Oct 2006 21:02:04 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>>>
Did you spot something in Jacob's code that was not C99-conforming?

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.
Are we? I'm not. Which leaves you talking to whom, about what, exactly?

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #109
Keith Thompson said:
Richard Heathfield <in*****@invalid.invalidwrites:
>Harald van D?k said:
>>Richard Heathfield wrote:
Harald van D?k said:

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?

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.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #110
Richard Heathfield <in*****@invalid.invalidwrites:
Mark McIntyre said:
>On Mon, 16 Oct 2006 02:01:57 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>>>Keith Thompson said:
Which explains your mistake, sir.

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 *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 strongly suggest you step back and take stock.

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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Oct 18 '06 #111
Richard Heathfield <in*****@invalid.invalidwrites:
Keith Thompson said:
>Richard Heathfield <in*****@invalid.invalidwrites:
>>Harald van D?k said:
Richard Heathfield wrote:
Harald van D?k said:

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?

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.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Oct 18 '06 #112
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.

<snip>
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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #113
Keith Thompson said:

<snip>
Here's the code fragment from PR19977:
<snip>
#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?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #114
Richard Heathfield <in*****@invalid.invalidwrites:
[...]
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Oct 18 '06 #115
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #116
Richard Heathfield wrote:
Keith Thompson said:

<snip>
Here's the code fragment from PR19977:

<snip>
#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.
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.

Oct 18 '06 #117
Harald van Dijk wrote:
Richard Heathfield wrote:
Keith Thompson said:

<snip>
Here's the code fragment from PR19977:
<snip>
#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.

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 should be "as old as 2.95.3", of course, sorry.
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.
Oct 18 '06 #118
Harald van D?k said:
Richard Heathfield wrote:
>Keith Thompson said:
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.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 18 '06 #119
Richard Heathfield posted:
>Stop this Richard, you're making a tit of yourself.

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.

--

Frederick Gotham
Oct 18 '06 #120
On Wed, 18 Oct 2006 20:53:36 GMT, in comp.lang.c , Frederick Gotham
<fg*******@SPAM.comwrote:
>Richard Heathfield posted:
>>Stop this Richard, you're making a tit of yourself.

It is not wise to insult people merely for disagreeing with you.
Its also pointless to reply to people who've plonked you. Other than
for self-gratification of course, which is probably fun but fairly
childish.
>Mark McIntyre is an thorough-bred asshole, plain and simple. I've yet to hear
him utter one pleasant syllable.
Then apparently you're incapable of reading.
--
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
Oct 18 '06 #121
[attribs fixed]

Mark McIntyre said:
>>Richard Heathfield posted:
>>Mark McIntyre said:
>>>Stop this Richard, you're making a tit of yourself.

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

Its also pointless to reply to people who've plonked you.
No, it isn't. Usenet is not email. Just because Mark can't read what I've
said (except by proxy, as in this case), that doesn't mean others can't.
And in fact sometimes it's actually a very good idea to reply to plonkers -
such as, for example, those times when they get their C wrong.

I do not keep track of those who either have or, at least, claim to have
killfiled me. That's their job, not mine. Just because they killfile me,
that doesn't mean their articles are free from my C crits.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 19 '06 #122

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Kenneth Downs | last post: by
13 posts views Thread by Paulo Pinto | last post: by
4 posts views Thread by Leif K-Brooks | last post: by
8 posts views Thread by Dan | last post: by
4 posts views Thread by Greg B | last post: by
1 post views Thread by steve smith | last post: by
26 posts views Thread by jacob navia | last post: by
4 posts views Thread by =?Utf-8?B?SmFu?= | last post: by
11 posts views Thread by Stef Mientki | last post: by
7 posts views Thread by bvdp | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.