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
Richard <rg****@gmail.comwrites:
[...]
Not all C code is intended to be portable. And C99 is a developing
standard ....
Not really, the C99 standard is reasonably stable. It's
implementations that are taking a while to catch up.

--
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 16 '06 #51
Keith Thompson said:
Richard Heathfield <in*****@invalid.invalidwrites:
<snip>
>If the OP had been someone with a track
record for being reasonable and rational and logical, I might have looked
more closely at the source after seeing how many diagnostics it
generated, and realised at that point that it used C99 features. But
since it was only our resident "all the world's a Win32 box running
lcc-win32"-er, I was not highly motivated to investigate the source of
the errors.

Which explains your mistake, sir.
I remain to be convinced that it was a mistake.

--
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 16 '06 #52
Richard Heathfield wrote:
Old Wolf said:
This is about as useful as asking why someone is left-shifting cout.

And, in its way, such a question is useful, insofar as it draws attention
(admittedly in a somewhat sideways manner) to the fact that C++ is not C,
and should be discussed in a C++ group rather than a C group.
I think the attention should be drawn in a more straightfoward
manner, instead of by willencuthery (i.e. pretending you don't
realise that it was C++ code, or in the case of the code in this
thread, pretending you didn't realise that the C++-style
comments were causing the errors).
Now, I fully accept that Mr Navia's code is /topical/ here in clc. There is
no question about that. My point is only that he has made his code
unnecessarily difficult to test because he has introduced C99isms
gratuitously.
I wouldn't call it 'gratuitously'. Many people consider that
declaring objects at the point of first use helps to avoid bugs.

Also, C++-style comments are somewhat faster to type,
and use up less horizontal space, and it is slightly easier
to manage multi-line comments.
Any compiler that claims any sort of C99 progress will
compile Navia's code. It's not as if // comments and
declarations after statements, are any sort of esoteric
language features. In fact, many C90 compilers support
those constructs as extensions anyway.

To enable those extensions in C90 compilers requires invoking them in
non-conforming mode, does it not?
Not necessarily -- a compiler in conforming mode is still allowed
to do whatever it likes with non-conforming code, as long as
a diagnostic is issued where required.

But that's besides my point: I suspect that even your dear
gcc 2.95 supports // comments and declarations after
statements, when invoked in its default manner. My point is
that such support is extremely widespread (even if you've
elected to turn it off for whatever reason).

Oct 16 '06 #53
Richard Heathfield <in*****@invalid.invalidwrites:
Keith Thompson said:
>Richard Heathfield <in*****@invalid.invalidwrites:
<snip>
>>If the OP had been someone with a track
record for being reasonable and rational and logical, I might have looked
more closely at the source after seeing how many diagnostics it
generated, and realised at that point that it used C99 features. But
since it was only our resident "all the world's a Win32 box running
lcc-win32"-er, I was not highly motivated to investigate the source of
the errors.

Which explains your mistake, sir.

I remain to be convinced that it was a mistake.
You responded to a chunk of legal code by posting a series of
misleading error messages, and didn't notice that the code is valid
C99.

jacob would have been better off avoiding "//" comments and mixed
declarations and statements in the code he posted, but you didn't pick
up on the *actual* problems with his code.

--
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 16 '06 #54
Old Wolf said:
Richard Heathfield wrote:
>Old Wolf said:
This is about as useful as asking why someone is left-shifting cout.

And, in its way, such a question is useful, insofar as it draws attention
(admittedly in a somewhat sideways manner) to the fact that C++ is not C,
and should be discussed in a C++ group rather than a C group.

I think the attention should be drawn in a more straightfoward
manner [...]
It would be a sad old world if we were all the same, wouldn't it?
>Now, I fully accept that Mr Navia's code is /topical/ here in clc. There
is no question about that. My point is only that he has made his code
unnecessarily difficult to test because he has introduced C99isms
gratuitously.

I wouldn't call it 'gratuitously'. Many people consider that
declaring objects at the point of first use helps to avoid bugs.
Yes, okay, that's a fair point. It's not an opinion I share, but yes, I hear
what you're saying.
Also, C++-style comments are somewhat faster to type,
and use up less horizontal space, and it is slightly easier
to manage multi-line comments.
/* 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.
Any compiler that claims any sort of C99 progress will
compile Navia's code. It's not as if // comments and
declarations after statements, are any sort of esoteric
language features. In fact, many C90 compilers support
those constructs as extensions anyway.

To enable those extensions in C90 compilers requires invoking them in
non-conforming mode, does it not?

Not necessarily -- a compiler in conforming mode is still allowed
to do whatever it likes with non-conforming code, as long as
a diagnostic is issued where required.
Fair comment. Mine issued plenty of diagnostics.
>
But that's besides my point: I suspect that even your dear
gcc 2.95 supports // comments and declarations after
statements, when invoked in its default manner.
Its default manner, however, is non-conforming.
My point is
that such support is extremely widespread (even if you've
elected to turn it off for whatever reason).
I've turned ON conforming mode, for what I hope is an obvious reason.

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.

--
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 16 '06 #55
Keith Thompson said:

<snip>
jacob would have been better off avoiding "//" comments and mixed
declarations and statements in the code he posted,
Quite so.
but you didn't pick
up on the *actual* problems with his code.
Had he done so, I might have done so. So he missed a trick there, if he was
after as many eyes as possible.

--
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 16 '06 #56
On Mon, 16 Oct 2006, Richard Heathfield wrote:
[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. As far as the current C standard is concerned,
a portable language construct is one that has well-defined
behaviour in the ISO 9899:1999 (E) document. Whether or not the
majority of real world compilers support it is IMHO a
/platform-specific/ issue and is therefore strictly speaking OT.
The C standard does not know or care about the specific
implementations that you happened to have access to, and if you
want to argue otherwise, Chapter and Verse please?

Tak-Shing
Oct 16 '06 #57
Tak-Shing Chan said:
On Mon, 16 Oct 2006, Richard Heathfield wrote:
>[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.

--
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 16 '06 #58
Richard Heathfield <in*****@invalid.invalidwrites:
Keith Thompson said:

<snip>
>jacob would have been better off avoiding "//" comments and mixed
declarations and statements in the code he posted,

Quite so.
>but you didn't pick
up on the *actual* problems with his code.

Had he done so, I might have done so. So he missed a trick there, if he was
after as many eyes as possible.
What you mean is, had he complied to your desires and not posted legal
C99 compliant code ...
Oct 16 '06 #59
Richard said:
Richard Heathfield <in*****@invalid.invalidwrites:
>Keith Thompson said:
>>but you didn't pick
up on the *actual* problems with his code.

Had he done so, I might have done so. So he missed a trick there, if he
was after as many eyes as possible.

What you mean is, had he complied to your desires and not posted legal
C99 compliant code ...
I have already said that his article was topical, so my desires are neither
here nor there. I have also already explained my meaning sufficiently
clearly, I think. See quoted text, above.

--
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 16 '06 #60
Richard Heathfield <in*****@invalid.invalidwrites:
Richard said:
>Richard Heathfield <in*****@invalid.invalidwrites:
>>Keith Thompson said:

but you didn't pick
up on the *actual* problems with his code.

Had he done so, I might have done so. So he missed a trick there, if he
was after as many eyes as possible.

What you mean is, had he complied to your desires and not posted legal
C99 compliant code ...

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.
--
Oct 16 '06 #61
Richard Heathfield wrote:
I only have two - K&R C and C90 - and of the two I choose C90. (No surprise
there.)
>I have the following command line options: Pretty strict it is too.

CFLAGS=-std=c99 -pedantic-errors -Wall -pthread -g $(DEBUGFLAGS)

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?
Oct 16 '06 #62
zebedee <ze*****@zebedee.netwrites:
Richard Heathfield wrote:
>I only have two - K&R C and C90 - and of the two I choose C90. (No
surprise there.)
>>I have the following command line options: Pretty strict it is too.

CFLAGS=-std=c99 -pedantic-errors -Wall -pthread -g $(DEBUGFLAGS)
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?
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.
Oct 16 '06 #63
zebedee said:
Richard Heathfield wrote:
>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.
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?

--
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 16 '06 #64
On Mon, 16 Oct 2006, Richard Heathfield wrote:
Tak-Shing Chan said:
>On Mon, 16 Oct 2006, Richard Heathfield wrote:
>>[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
Oct 16 '06 #65
Tak-Shing Chan said:
On Mon, 16 Oct 2006, Richard Heathfield wrote:
>Tak-Shing Chan said:
>> 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?
Whatever.

--
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 16 '06 #66
Richard Heathfield posted:
> Pray tell, where did I say /anything/ about your intent?

Whatever.

I wish my newsreader had an automatic "vacuous post" detector.

--

Frederick Gotham
Oct 16 '06 #67
in 701475 20061016 094846 Richard <rg****@gmail.comwrote:
>What you mean is, had he complied to your desires ...
Did you mean "complied with"? Must get these things right, mustn't we?
Oct 16 '06 #68
zebedee <ze*****@zebedee.netwrites:
Richard Heathfield wrote:
>I only have two - K&R C and C90 - and of the two I choose C90. (No
surprise there.)
>>I have the following command line options: Pretty strict it is too.

CFLAGS=-std=c99 -pedantic-errors -Wall -pthread -g $(DEBUGFLAGS)
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.
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.

--
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 16 '06 #69

Richard Heathfield wrote:
>
/* 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.

--
Bill Pursell

Oct 17 '06 #70
Keith Thompson wrote:
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 8-). 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];
Oct 17 '06 #71
zebedee wrote:
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.

Oct 17 '06 #72
jacob navia wrote:
zebedee wrote:
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.)

Oct 17 '06 #73
jacob navia wrote:
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? 8-)

int f (e)
int e[sizeof (enum e { e1 = 3 })];
{
return e[e1];
}
Oct 17 '06 #74
zebedee wrote:
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? 8-)

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?

Oct 17 '06 #75
Harald van Dijk wrote:
zebedee wrote:
>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? 8-)

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 8-) 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.
Oct 17 '06 #76
zebedee wrote:
Harald van Dijk wrote:
>zebedee wrote:
>>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? 8-)

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 8-) 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
Oct 17 '06 #77
zebedee said:

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

--
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 17 '06 #78
Richard Heathfield wrote:
zebedee said:

<snip>
>>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.
Oct 17 '06 #79
Richard Heathfield wrote:
zebedee said:

<snip>

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.

Oct 17 '06 #80
zebedee <ze*****@zebedee.netwrites:
Keith Thompson wrote:
>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 8-). 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.htmlis a summary of the current
status. Is there, or should there be, a similar table for C90?

--
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 #81
Harald van D?k said:
Richard Heathfield wrote:
>>
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.
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?

--
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 17 '06 #82
Bill Pursell <bi**********@gmail.comwrote:
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.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Oct 17 '06 #83
Richard Heathfield wrote:
Harald van D?k said:
Richard Heathfield wrote:
>
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.

Hardly strictly conforming...
Replace __builtin_abort() with abort() (and add #include <stdlib.h>),
and it is (unless I'm blind).
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.

Oct 17 '06 #84
Keith Thompson <ks***@mib.orgwrites:
[...]
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.

--
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 #85
On Sun, 15 Oct 2006 21:02:04 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>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
Oct 17 '06 #86
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.
>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
Oct 17 '06 #87
On Sun, 15 Oct 2006 22:38:50 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>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
Oct 17 '06 #88
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.

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
Oct 17 '06 #89
On Mon, 16 Oct 2006 13:50:55 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>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
Oct 17 '06 #90
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, 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
Oct 17 '06 #91
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 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
Oct 17 '06 #92
On Mon, 16 Oct 2006 03:55:37 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>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
Oct 17 '06 #93
On Mon, 16 Oct 2006 14:47:59 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>Tak-Shing Chan said:
>On Mon, 16 Oct 2006, Richard Heathfield wrote:
>>Tak-Shing Chan said:

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?

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
Oct 17 '06 #94
Mark McIntyre <ma**********@spamcop.netwrites:
On Sun, 15 Oct 2006 23:36:08 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>>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 (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 #95
Mark McIntyre <ma**********@spamcop.netwrites:
On Mon, 16 Oct 2006 14:47:59 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>>Tak-Shing Chan said:
>>On Mon, 16 Oct 2006, Richard Heathfield wrote:

Tak-Shing Chan said:

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?

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

--
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 #96
jacob navia wrote:
>>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 8-) 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.
Oct 17 '06 #97
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.
Oct 17 '06 #98
On Tue, 17 Oct 2006 21:09:45 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:
>Mark McIntyre <ma**********@spamcop.netwrites:
>On Sun, 15 Oct 2006 23:36:08 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>>>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
Oct 17 '06 #99
On Tue, 17 Oct 2006 21:15:10 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:
>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
Oct 17 '06 #100

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
reply views Thread by kmladenovski | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.