By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,247 Members | 1,223 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,247 IT Pros & Developers. It's quick & easy.

A simple parser

P: n/a
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 #1
Share this Question
Share on Google+
121 Replies


P: n/a

jacob navia wrote:
>It scans for a terminating parentheses and an immediately
following opening brace.
Um, can't if() and while() statements have that sequence?
A better strategy might be to count curly brackets. If the nesting
level of curlys is zero, then you're at the top level. Anything that
has parens is probably a function declaration.

Of course there's the problem of macros,which I'm sure you don't want
to handle yourself. Maybe run cpp and pipe its output to your program?

Oct 15 '06 #2

P: n/a
jacob navia wrote:
>
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.
.... snip ...
>
// 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 this one example will do. Obvious problems:

1. Excessive indentation. Later it makes lines much too long.
Use spaces, not tabs, and indent by 3 or 4 places.

2. Use of // comments in Usenet. Causes nasty line wrapping
problems.

3. Faulty code. There is no guarantee 'a' .. 'z' etc. are
contiguous, in any specific order, etc.

4. Doesn't handle EOF.

Here is a sample of some code that may do what you want. It
doesn't allow line continuation within identifiers. You would
probably need to control '{' and '}' matching within skiptoident.

/* skips and echoes all characters that cannot start an
identifier. echoto may be NULL, to suppress any echoing
Returns the starting char for the following identifier,
which may be EOF and is still in the input stream.
*/
static int skiptoident(FILE *f, FILE *echoto)
{
int ch;

do {
ch = getc(f);
if (('_' == ch) || isalpha(ch)) break;
if (echoto && (EOF != ch)) putc(ch, echoto);
} while (EOF != ch);
ungetc(ch, f);
return ch;
} /* skiptoident */

/* ----------------- */

/* generic function to extract the next identifier from a stream
Identifiers can begin with _ or alpha, and continue until a
non-alpha non _ non-numeric char is encountered.
'\0' terminate the string.
Leading chars that do not fit an identifier are echoed.
echoto may be NULL, to suppress any echoing
Returns char terminating the identifier, which is 'ungotten'
buf[bmax] should be valid storage space.
*/
static int getident(char *buf, int bmax, FILE *f, FILE *echoto)
{
int ch, ix;

if (EOF == skiptoident(f, echoto)) ch = EOF;
else ch = getc(f);
/* Here the input stream has been absorbed and echoed */
/* up to the first character of an identifier, in ch */
ix = 0;
while (('_' == ch) || isalnum(ch)) { /* skips on eof */
buf[ix++] = ch;
ch = getc(f);
if (ix >= bmax) break;
}
buf[ix] = '\0';
ungetc(ch, f);
return ch;
} /* getident */

These are extracts from id2id which has to do some elementary C
lexing, and is available on my site:

<http://cbfalconer.home.att.net/download/

PS: I find you have committed the sin of multi-posting, so I have
cross-posted this response. Luckily I didn't go back on line
before checking the lcc group.

--
"I don't know where bin Laden is. I have no idea and really
don't care. It's not that important." - G.W. Bush, 2002-03-13
"No, we've had no evidence that Saddam Hussein was involved
with September the 11th." - George Walker Bush 2003-09-17
Oct 15 '06 #3

P: n/a
jacob navia said:
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.
foo.c:12: parse error before `/'
foo.c:17: stray '\' in program
foo.c:54: warning: type defaults to `int' in declaration of `IdBuffer'
foo.c:54: warning: ANSI C forbids zero-size array `IdBuffer'
foo.c:54: `c' undeclared here (not in a function)
foo.c:54: ANSI C forbids data definition with no type or storage class
foo.c:55: parse error before `while'
foo.c:64: `i' undeclared here (not in a function)
foo.c:64: warning: type defaults to `int' in declaration of `IdBuffer'
foo.c:64: variable `IdBuffer' has initializer but incomplete type
foo.c:64: conflicting types for `IdBuffer'
foo.c:54: previous declaration of `IdBuffer'
foo.c:64: ANSI C forbids data definition with no type or storage class
foo.c:65: parse error before `return'
foo.c:69: parse error before `/'
foo.c:83: parse error before `/'
foo.c:92: warning: type defaults to `int' in declaration of `c'
foo.c:92: warning: implicit declaration of function `Fgetc'
foo.c:92: `f' undeclared here (not in a function)
foo.c:92: initializer element is not constant
foo.c:92: ANSI C forbids data definition with no type or storage class
foo.c:93: parse error before `if'
foo.c:99: parse error before `/'
foo.c: In function `main':
foo.c:152: parse error before `*'
foo.c:153: `f' undeclared (first use in this function)
foo.c:153: (Each undeclared identifier is reported only once
foo.c:153: for each function it appears in.)
foo.c:157: parse error before `int'
foo.c:162: parse error before `/'
foo.c:168: case label not within a switch statement
foo.c:171: warning: implicit declaration of function `ParseComment'
foo.c:173: warning: implicit declaration of function `ParseCppComment'
foo.c:175: case label not within a switch statement
foo.c:176: warning: implicit declaration of function `ParseQuotedChar'
foo.c:178: case label not within a switch statement
foo.c:179: `level' undeclared (first use in this function)
foo.c:182: case label not within a switch statement
foo.c:183: `inFunction' undeclared (first use in this function)
foo.c:184: `line' undeclared (first use in this function)
foo.c:191: case label not within a switch statement
foo.c:192: `parenlevel' undeclared (first use in this function)
foo.c:195: case label not within a switch statement
foo.c:200: warning: implicit declaration of function `SkipWhiteSpace'
foo.c:204: warning: implicit declaration of function `PrintFunction'
foo.c:208: default label not within a switch statement
foo.c:210: warning: implicit declaration of function `IsIdentifier'
foo.c:211: warning: implicit declaration of function `ReadId'
foo.c: At top level:
foo.c:215: warning: type defaults to `int' in declaration of `fclose'
foo.c:215: warning: parameter names (without types) in function declaration
foo.c:215: ANSI C forbids data definition with no type or storage class
foo.c:216: parse error before `return'
make: *** [foo.o] Error 1

--
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 15 '06 #4

P: n/a
Richard Heathfield <in*****@invalid.invalidwrites:
jacob navia said:
>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.

foo.c:12: parse error before `/'
foo.c:17: stray '\' in program
[51 lines deleted]
make: *** [foo.o] Error 1
Every one of those errors is caused by two things: "//" comments and
mixed declarations and statements.

The code compiles without error with "gcc -std=c99". It also compiles
without error with "gcc -ansi -pedantic" if I remove the "//" comments
and move a few object declarations.

It is, as far as I can tell, valid C99.

I understand and agree with your reasons for using a strict C90
compiler, but not everyone does so.

--
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 15 '06 #5

P: n/a
Keith Thompson said:
Richard Heathfield <in*****@invalid.invalidwrites:
>jacob navia said:
>>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.

foo.c:12: parse error before `/'
foo.c:17: stray '\' in program
[51 lines deleted]
>make: *** [foo.o] Error 1

Every one of those errors is caused by two things: "//" comments and
mixed declarations and statements.
<shrugI figured it had to be something like that. So - does anyone have a
conforming C99 compiler that we can use to test Mr Navia's code? No? Oh
well.
The code compiles without error with "gcc -std=c99".
Er, so what? Despite the misleading switch-name, gcc is not a C99-conforming
compiler.
It also compiles
without error with "gcc -ansi -pedantic" if I remove the "//" comments
and move a few object declarations.
That, in my view, is the author's job, not yours or mine. (And it shows that
the C99isms have been adopted gratuitously, presumably to make the code
less portable. Why anyone should wish to do this is beyond me.)
It is, as far as I can tell, valid C99.

I understand and agree with your reasons for using a strict C90
compiler, but not everyone does so.
Well, my principal reason for using a strict C90 compiler is simple - it's
so that I can be sure that /my/ code doesn't use any C99isms, because I
want /my/ code to compile everywhere, not just on the vanishingly small
number of conforming C99 implementations.

--
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 15 '06 #6

P: n/a
Ancient_Hacker wrote:
jacob navia wrote:
>>It scans for a terminating parentheses and an immediately
following opening brace.


Um, can't if() and while() statements have that sequence?
A better strategy might be to count curly brackets. If the nesting
level of curlys is zero, then you're at the top level. Anything that
has parens is probably a function declaration.
Well I *do* count parens and brackets.... See the code
>
Of course there's the problem of macros,which I'm sure you don't want
to handle yourself. Maybe run cpp and pipe its output to your program?
Macros will be assumed function calls, but not function definitions...

I should ignore # lines, that would make it more robust.
Oct 15 '06 #7

P: n/a
CBFalconer wrote:
jacob navia wrote:
>>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.

... snip ...
>>// 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 this one example will do. Obvious problems:

1. Excessive indentation. Later it makes lines much too long.
Use spaces, not tabs, and indent by 3 or 4 places.
OK
2. Use of // comments in Usenet. Causes nasty line wrapping
problems.
OK
3. Faulty code. There is no guarantee 'a' .. 'z' etc. are
contiguous, in any specific order, etc.
Mmmm, it *could* be, but I have never found a machine where they aren't
contiguous...
4. Doesn't handle EOF.
Why? It returns 0 at EOF, and EOF is NOT an identifier char, so it is
correct...
Here is a sample of some code that may do what you want. It
doesn't allow line continuation within identifiers. You would
probably need to control '{' and '}' matching within skiptoident.

/* skips and echoes all characters that cannot start an
identifier. echoto may be NULL, to suppress any echoing
Returns the starting char for the following identifier,
which may be EOF and is still in the input stream.
*/
static int skiptoident(FILE *f, FILE *echoto)
{
int ch;

do {
ch = getc(f);
if (('_' == ch) || isalpha(ch)) break;
if (echoto && (EOF != ch)) putc(ch, echoto);
} while (EOF != ch);
ungetc(ch, f);
return ch;
} /* skiptoident */
This is interesting since it would eliminate the need for a
buffer. The problem is that

typedef struct _tagFoo {
int a;
} FOO;

would print the _tagfoo...

I can't decide whether an indentifier is really a function until
I see a ')' followed by {, so I can't put it out immediately.

But I see the point of '_' || isalpha(c)

It is much better. Thanks.

/* ----------------- */

/* generic function to extract the next identifier from a stream
Identifiers can begin with _ or alpha, and continue until a
non-alpha non _ non-numeric char is encountered.
'\0' terminate the string.
Leading chars that do not fit an identifier are echoed.
echoto may be NULL, to suppress any echoing
Returns char terminating the identifier, which is 'ungotten'
buf[bmax] should be valid storage space.
*/
static int getident(char *buf, int bmax, FILE *f, FILE *echoto)
{
int ch, ix;

if (EOF == skiptoident(f, echoto)) ch = EOF;
else ch = getc(f);
/* Here the input stream has been absorbed and echoed */
/* up to the first character of an identifier, in ch */
ix = 0;
while (('_' == ch) || isalnum(ch)) { /* skips on eof */
buf[ix++] = ch;
ch = getc(f);
if (ix >= bmax) break;
}
buf[ix] = '\0';
ungetc(ch, f);
return ch;
} /* getident */

These are extracts from id2id which has to do some elementary C
lexing, and is available on my site:

<http://cbfalconer.home.att.net/download/

PS: I find you have committed the sin of multi-posting, so I have
cross-posted this response. Luckily I didn't go back on line
before checking the lcc group.
Oct 15 '06 #8

P: n/a
Keith Thompson wrote:
Richard Heathfield <in*****@invalid.invalidwrites:
>>jacob navia said:

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

foo.c:12: parse error before `/'
foo.c:17: stray '\' in program

[51 lines deleted]
>>make: *** [foo.o] Error 1


Every one of those errors is caused by two things: "//" comments and
mixed declarations and statements.

The code compiles without error with "gcc -std=c99". It also compiles
without error with "gcc -ansi -pedantic" if I remove the "//" comments
and move a few object declarations.

It is, as far as I can tell, valid C99.

I understand and agree with your reasons for using a strict C90
compiler, but not everyone does so.
Since you compiled Keith, can you pass it through some
C code... Does it work?

jacob
Oct 15 '06 #9

P: n/a
jacob navia said:
CBFalconer wrote:
<snip>
>3. Faulty code. There is no guarantee 'a' .. 'z' etc. are
contiguous, in any specific order, etc.

Mmmm, it *could* be, but I have never found a machine where they aren't
contiguous...
That doesn't mean such machines don't exist. I've spent several years
working on such machines. Look up "EBCDIC" in Google.

<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 15 '06 #10

P: n/a


On Oct 15, 2:42*pm, Richard Heathfield <inva...@invalid.invalid>
wrote:
jacob navia said:
CBFalconer wrote:<snip>
3. *Faulty code. *There is no guarantee 'a' .. 'z' etc. are
contiguous, in any specific order, etc.
Mmmm, it *could* be, but I have never found a machine where they aren't
contiguous...That doesn't mean such machines don't exist. I've spent several years
working on such machines. Look up "EBCDIC" in Google.

Yeah. In fact, C99 gives us little guarantee about how characters are
portable. The following is found in C99 5.2.1:

A byte with all bits set to 0, called the null character,
shall exist in the basic execution character set; it is used to
terminate a character string.

Both the basic source and basic execution character sets shall have the
following members: the 26 uppercase letters of the Latin alphabet
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z
the 26 lowercase letters of the Latin alphabet
a b c d e f g h i j k l m
n o p q r s t u v w x y z
the 10 decimal digits
0 1 2 3 4 5 6 7 8 9
the following 29 graphic characters
! " # % & ' ( ) * + , - . /
:
; < = ? [ \ ] ^ _ { | } ~
the space character, and control characters representing horizontal
tab, vertical tab, and form feed. The representation of each member of
the source and execution basic
character sets shall fit in a byte. In both the source and execution
basic character sets, the value of each character after 0 in the above
list of decimal digits shall be one greater than
the value of the previous. In source files, there shall be some way of
indicating the end of each line of text; this International Standard
treats such an end-of-line indicator as if it
were a single new-line character. In the basic execution character set,
there shall be control characters representing alert, backspace,
carriage return, and new line.

Oct 15 '06 #11

P: n/a


"Keith Thompson" <ks***@mib.orgwrote in message
>
Every one of those errors is caused by two things: "//" comments and
mixed declarations and statements.
I decided that surely, slash slash comments were so widespread by now that I
could use them.
Only to have my code break on the next complier, a parallel job.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

Oct 15 '06 #12

P: n/a
On Sun, 15 Oct 2006 06:42:06 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:
>jacob navia said:
>CBFalconer wrote:

<snip>
>>3. Faulty code. There is no guarantee 'a' .. 'z' etc. are
contiguous, in any specific order, etc.

Mmmm, it *could* be, but I have never found a machine where they aren't
contiguous...

That doesn't mean such machines don't exist. I've spent several years
working on such machines. Look up "EBCDIC" in Google.
<snip>
Also BCD, as used on a 14xx series system. (came before "EBCDIC") :-)
--
ArarghMail610 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.
Oct 15 '06 #13

P: n/a
On Sun, 15 Oct 2006 07:55:01 +0200, jacob navia wrote:
>CBFalconer wrote:
>3. Faulty code. There is no guarantee 'a' .. 'z' etc. are
contiguous, in any specific order, etc.

Mmmm, it *could* be, but I have never found a machine where they aren't
contiguous...
What's wrong with isalpha and similar functions?

Best wishes,
Roland Pibinger
Oct 15 '06 #14

P: n/a
Roland Pibinger wrote:
On Sun, 15 Oct 2006 07:55:01 +0200, jacob navia wrote:
>>CBFalconer wrote:
>>>3. Faulty code. There is no guarantee 'a' .. 'z' etc. are
contiguous, in any specific order, etc.

Mmmm, it *could* be, but I have never found a machine where they aren't
contiguous...


What's wrong with isalpha and similar functions?

Best wishes,
Roland Pibinger
Yes, I will change that as proposed by Chuck.
Oct 15 '06 #15

P: n/a
On Sun, 15 Oct 2006 00:27:43 +0200, jacob navia wrote:
>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.
[...]
>static char IdBuffer[MAXID]; // Buffer for remembering the function name
static int line = 1; // We start at line 1
Why statics? They make your code non-reusable. BTW, if you also made
FILE *f and int c static here you (almost) wouldn't have to pass any
arguments to your functions. IMO, non-const globals (statics) should
be avoided in a C tutorial (because they should be avoided in a C
program).
>static int Fgetc(FILE *f)
Why are the functions static? That's only confusing for a newbie.
>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;
}
Hmm, goto in a C tutorial? You could add an exercise for the reader:
'Enhance the clarity of this function by rewriting it with one return
statement and without using goto'.

Best regards,
Roland Pibinger
Oct 15 '06 #16

P: n/a
Ar*****************@NOT.AT.Arargh.com writes:
On Sun, 15 Oct 2006 06:42:06 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:
>>jacob navia said:
>>CBFalconer wrote:

<snip>
>>>3. Faulty code. There is no guarantee 'a' .. 'z' etc. are
contiguous, in any specific order, etc.
Mmmm, it *could* be, but I have never found a machine where they aren't
contiguous...

That doesn't mean such machines don't exist. I've spent several years
working on such machines. Look up "EBCDIC" in Google.
<snip>
Also BCD, as used on a 14xx series system. (came before "EBCDIC") :-)
BCD is worse, not only there are not contiguous, they aren't even in order.

Yours,

--
Jean-Marc
Oct 15 '06 #17

P: n/a
Roland Pibinger wrote:
On Sun, 15 Oct 2006 00:27:43 +0200, jacob navia wrote:
>>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.

[...]
>>static char IdBuffer[MAXID]; // Buffer for remembering the function name
static int line = 1; // We start at line 1


Why statics? They make your code non-reusable. BTW, if you also made
FILE *f and int c static here you (almost) wouldn't have to pass any
arguments to your functions. IMO, non-const globals (statics) should
be avoided in a C tutorial (because they should be avoided in a C
program).
If you make global variables visible by other parts of the
program this can lead to name conflicts.

Making global variables static limits their scope and
allows for code reuse. Actually I believe the
contrary is true. I think the code is more reusable
BECAUSE it will export just ONE function.
>
>>static int Fgetc(FILE *f)


Why are the functions static? That's only confusing for a newbie.
No. See above.
>
>>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;
}


Hmm, goto in a C tutorial? You could add an exercise for the reader:
'Enhance the clarity of this function by rewriting it with one return
statement and without using goto'.

Best regards,
Roland Pibinger

I believe goto is not bad when used correctly. It is part of the
language anyway, and if used correctly it is perfectly OK.

Care to solve your problem?

I will add it to the tutorial.
Oct 15 '06 #18

P: n/a
Jean-Marc Bourguet wrote:
Ar*****************@NOT.AT.Arargh.com writes:

>>On Sun, 15 Oct 2006 06:42:06 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:

>>>jacob navia said:
CBFalconer wrote:

<snip>

>3. Faulty code. There is no guarantee 'a' .. 'z' etc. are
>contiguous, in any specific order, etc.
>

Mmmm, it *could* be, but I have never found a machine where they aren't
contiguous...

That doesn't mean such machines don't exist. I've spent several years
working on such machines. Look up "EBCDIC" in Google.
<snip>

Also BCD, as used on a 14xx series system. (came before "EBCDIC") :-)


BCD is worse, not only there are not contiguous, they aren't even in order.

Yours,
Well, EBCDIC was a 7 bit code, used for punched cards. The eighth bit
was there to signal the card reader that a character was in that column.

Using only 7 bits, the codes are continuous. When punched cards weren't
so much used (approx beginning of the 80es) IBM added foreign language
characters in those positions.

This has a maybe anectodical importance, but its practical impact is ...

Anyway Chuck was right and I changed that.
Oct 15 '06 #19

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
Jean-Marc Bourguet wrote:
>Ar*****************@NOT.AT.Arargh.com writes:
>>>On Sun, 15 Oct 2006 06:42:06 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:
jacob navia said:
>CBFalconer wrote:

<snip>

>>3. Faulty code. There is no guarantee 'a' .. 'z' etc. are
>>contiguous, in any specific order, etc.
>>
>
>Mmmm, it *could* be, but I have never found a machine where they aren't
>contiguous...

That doesn't mean such machines don't exist. I've spent several years
working on such machines. Look up "EBCDIC" in Google.
<snip>

Also BCD, as used on a 14xx series system. (came before "EBCDIC") :-)
BCD is worse, not only there are not contiguous, they aren't even in
order.
BTW, BCD is a 6 bits code which would be unsuitable for C, there are no
lower case letters and the digits are contiguous but not in numerical
order (0 is after 9)
Well, EBCDIC was a 7 bit code, used for punched cards.
While it is true that EBCDIC was strongly constrained by punched cards,
EBCDIC was a 8 bit code since its inconception. And the number of
codepoint defined was not constrained by punched cards considerations but
by keyboard, printer and typewriter one.
The eighth bit
was there to signal the card reader that a character was in that column.
Using only 7 bits, the codes are continuous.
I wonder if you ever saw a table. Here is one, now just give me the bit to
ignore so that A-Z are contiguous:

0 1 2 3 4 5 6 7 8 9 A B C D E F
0 & - 0
1 / a j A J 1
2 b k s B K S 2
3 c l t C L T 3
4 d m u D M U 4
5 e n v E N V 5
6 f o w F O W 6
7 g p x G P X 7
8 h q y H Q Y 8
9 i r z I R Z 9
A NL NL
B . NU , NU
C < * % NU
D ( ) _ '
E + ; =
F | ~ ? NL

When punched cards weren't so much used (approx beginning of the 80es)
IBM added foreign language characters in those positions.
National were present since its inconception. The table shows the reserved
position with NL (national lowercase) NU (national uppercase). The constraint
constraint
This has a maybe anectodical importance, but its practical impact is ...
EBCDIC is still alive on IBM mainframes. And I'd not be surprised if the
volume of data stored in EBCDIC was still greater than the volume of data
stored in codesets compatible with ISO-646.

Yours,

--
Jean-Marc
Oct 15 '06 #20

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
Well, EBCDIC was a 7 bit code, used for punched cards. The eighth bit
was there to signal the card reader that a character was in that column.

Using only 7 bits, the codes are continuous.
Did not match my recollection so I tried:

echo -n ABCDEFGHIJKLMNOPQRSTUVWXYZ | iconv -f ascii -t ebcdic-us | od -t x1

and got:

0000000 c1 c2 c3 c4 c5 c6 c7 c8 c9 d1 d2 d3 d4 d5 d6 d7
0000020 d8 d9 e2 e3 e4 e5 e6 e7 e8 e9

--
Ben.
Oct 15 '06 #21

P: n/a
jacob navia said:

<snip>
>
Using only 7 bits, the codes are continuous.
Rubbish.

EBCDIC encoding of a-z:

From a to i: 81 to 89
8A to 90 Other stuff
From j to r: 91 to 99
9A to A1 Other stuff
From s to z: A2 to A9

EBCDIC encoding of A-Z:

From A to I: C1 to C9
CA to D0 Other stuff
From J to R: D1 to D9
9A to A1 Other stuff
From s to z: E2 to E9

--
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 15 '06 #22

P: n/a
Roland Pibinger wrote:
On Sun, 15 Oct 2006 00:27:43 +0200, jacob navia wrote:
.... snip ...
>>
static int Fgetc(FILE *f)

Why are the functions static? That's only confusing for a newbie.
Because they are not used outside that module. This avoids name
space pollution. Routine.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Oct 15 '06 #23

P: n/a
Richard Heathfield <in*****@invalid.invalidwrites:
Keith Thompson said:
>Richard Heathfield <in*****@invalid.invalidwrites:
>>jacob navia said:
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.

foo.c:12: parse error before `/'
foo.c:17: stray '\' in program
[51 lines deleted]
>>make: *** [foo.o] Error 1

Every one of those errors is caused by two things: "//" comments and
mixed declarations and statements.

<shrugI figured it had to be something like that. So - does anyone have a
conforming C99 compiler that we can use to test Mr Navia's code? No? Oh
well.
I don't, but I understand that some people do.
>The code compiles without error with "gcc -std=c99".

Er, so what? Despite the misleading switch-name, gcc is not a C99-conforming
compiler.
I never said it was. I do however, have access to a compiler that
implements enough of a subset of C99 to cpomile jacob's code. I
suspect you do too; if I recall correctly, the older version of gcc
that you use doesn't support the "-std=c99" option, but it does, in
some modes, support "//" comments and mixed declarations and code.

It also does a lousy job of diagnosing errors introduced by using C99
constructs. Use of "//" is such a common error that the compiler
should recognize it and issue a specific diagnostic. (I just tried
gcc 4.1.1; it does a little better, but it still treats the "//" as a
simple syntax error.)

--
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 15 '06 #24

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
[...]
>>>On Sun, 15 Oct 2006 06:42:06 +0000, Richard Heathfield
<in*****@invalid.invalidwrote:
jacob navia said:
[...]
>>>>>Mmmm, it *could* be, but I have never found a machine where they aren't
>contiguous...

That doesn't mean such machines don't exist. I've spent several
years working on such machines. Look up "EBCDIC" in Google.
[snip]
Well, EBCDIC was a 7 bit code, used for punched cards. The eighth bit
was there to signal the card reader that a character was in that column.

Using only 7 bits, the codes are continuous. When punched cards weren't
so much used (approx beginning of the 80es) IBM added foreign language
characters in those positions.
You didn't look up "EBCDIC" in Google, did you?

--
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 15 '06 #25

P: n/a
rp*****@yahoo.com (Roland Pibinger) writes:
On Sun, 15 Oct 2006 00:27:43 +0200, jacob navia wrote:
[...]
>>static int Fgetc(FILE *f)

Why are the functions static? That's only confusing for a newbie.
Only to a newbie who doesn't know about static functions.

(IMHO, functions should be static by default, and exported to other
translation units only if specified. But of course it's way too late
to change that.)
>>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;
}

Hmm, goto in a C tutorial? You could add an exercise for the reader:
'Enhance the clarity of this function by rewriting it with one return
statement and without using goto'.
*Some* gotos are ok; for example, it can be a decent way to jump to
error-handling code at the end of a function. (It makes up for C's
lack of multi-level break or a decent exception-handling mechanism.)

But this particular goto branches backward, which is potentially
dangerous. Fortunately, C has a structured equivalent of a backward
goto: a loop. Translating the code to use a loop is left as an
exercise for the author.

--
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 15 '06 #26

P: n/a
Hello,

jacob navia wrote:
>>>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;
}
[...]
I believe goto is not bad when used correctly. It is part of the
language anyway, and if used correctly it is perfectly OK.
Yes, if used correctly. Unfortunately, in your case, it can be avoided
*very* easily. Thus, in my view, it is not used correctly here. ;)

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
Oct 15 '06 #27

P: n/a
On Sun, 15 Oct 2006 12:18:11 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

(of EBCDIC)
>
This has a maybe anectodical importance, but its practical impact is ...
Hey, did they shut down all the IBM mainframes? Wow, thats gonna
reduce the carbon deficit, for sure.

:-)

Hardly anecdotal.
Hate to say it Jacob, but you're back in the "All the words a Vax"
tunnel.

--
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 15 '06 #28

P: n/a
On Sun, 15 Oct 2006 04:58:23 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>Keith Thompson said:
>Richard Heathfield <in*****@invalid.invalidwrites:
>>foo.c:12: parse error before `/'
(etc)
>>
Every one of those errors is caused by two things: "//" comments and
mixed declarations and statements.

<shrugI figured it had to be something like that. So - does anyone have a
conforming C99 compiler that we can use to test Mr Navia's code? No? Oh
well.
Don't be childish. It ill becomes you.
>The code compiles without error with "gcc -std=c99".

Er, so what? Despite the misleading switch-name, gcc is not a C99-conforming
compiler.
Did you spot something in Jacob's code that was not C99-conforming?
Did you bother? Next time, engage your brain before posting, and
recall that if you plan to occupy the moral high ground, you need to
actually stand on it first.
--
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 15 '06 #29

P: n/a
Mark McIntyre said:
On Sun, 15 Oct 2006 04:58:23 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:
>>Keith Thompson said:
>>Richard Heathfield <in*****@invalid.invalidwrites:
>>>foo.c:12: parse error before `/'
(etc)
>>>
Every one of those errors is caused by two things: "//" comments and
mixed declarations and statements.

<shrugI figured it had to be something like that. So - does anyone have
a conforming C99 compiler that we can use to test Mr Navia's code? No? Oh
well.

Don't be childish. It ill becomes you.
Hmm? Does that mean you /do/ have a C99 conforming compiler? Fabulous - let
us know how it goes.

>>The code compiles without error with "gcc -std=c99".

Er, so what? Despite the misleading switch-name, gcc is not a
C99-conforming compiler.

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
feature so vital that it justified making the code non-C90-conforming?

<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 15 '06 #30

P: n/a
Richard Heathfield wrote:
Mark McIntyre said:

>>On Sun, 15 Oct 2006 04:58:23 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>>>Keith Thompson said:
Richard Heathfield <in*****@invalid.invalidwrites:
>>>>>foo.c:12: parse error before `/'

(etc)
>>>>Every one of those errors is caused by two things: "//" comments and
mixed declarations and statements.

<shrugI figured it had to be something like that. So - does anyone have
a conforming C99 compiler that we can use to test Mr Navia's code? No? Oh
well.

Don't be childish. It ill becomes you.


Hmm? Does that mean you /do/ have a C99 conforming compiler? Fabulous - let
us know how it goes.
>>>>The code compiles without error with "gcc -std=c99".

Er, so what? Despite the misleading switch-name, gcc is not a
C99-conforming compiler.

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
feature so vital that it justified making the code non-C90-conforming?

<snip>
You change your arguments heathfield. First you tell there isn't any c99
compiler, then you argue that c99 is not needed.

There is nothing in the code that needs to be c90 either. I could have
written it in K&R C, without prototypes syntax.

But I am not in a nostalgia trip, I believe C evolves and I like it like
that.

Can't you contribute anything substantial to the discussion?
Just empty polemic?

So far there is nothing in your arguments worth mentioning...

What about the algorithm? You see any flaws in there?

P.S. And please do not start with EBCDIC, I changed that to use
isalpha() ...
Oct 15 '06 #31

P: n/a
jacob navia said:
Richard Heathfield wrote:
>>
Did you spot something in the code that *needed* a C99 feature, a
feature so vital that it justified making the code non-C90-conforming?

You change your arguments heathfield.
Not so.
First you tell there isn't any c99 compiler,
There are very few.
then you argue that c99 is not needed.
If C99 compilers were commonplace, this would indeed be a pointless
argument. But since they are rarer than rocking-horse food, it makes sense
not to rely on C99 features if you don't need to.
There is nothing in the code that needs to be c90 either. I could have
written it in K&R C, without prototypes syntax.
Sure - but C90 compilers are all over the place, so there wouldn't be any
point in writing it for K&R C.
But I am not in a nostalgia trip,
No, you're on a trip to the future. Have a great time, and let us know when
you get back.
I believe C evolves and I like it like that.

Can't you contribute anything substantial to the discussion?
This /is/ substantial, unless your position is that you like your code to
fail to compile on most extant conforming implementations. If that is the
case, fine, be happy, win awards, whatever.

And my character set point was substantial, too. But you tried to handwave
that away, as usual (by inventing a pseudohistory for EBCDIC that bore no
relation to the facts). And you got caught, as usual.
Just empty polemic?
No, a genuine effort to help you to write code that more people can use. If
you persist in seeing portability as a negative, however, you will continue
to misunderstand me.
So far there is nothing in your arguments worth mentioning...
It is because you believe this that you fail.
What about the algorithm? You see any flaws in there?
When you submit a C90-conforming version that I can compile, I'll take a
look.
>
P.S. And please do not start with EBCDIC, I changed that to use
isalpha() ...
Well, there's a thing.

--
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 15 '06 #32

P: n/a
Richard Heathfield wrote:
Keith Thompson said:
>>It also compiles
without error with "gcc -ansi -pedantic" if I remove the "//" comments
and move a few object declarations.


That, in my view, is the author's job, not yours or mine. (And it shows that
the C99isms have been adopted gratuitously, presumably to make the code
less portable. Why anyone should wish to do this is beyond me.)
Oh no, the sky is falling, someone has posted code using some C99 features.

--
Ian Collins.
Oct 15 '06 #33

P: n/a
Ian Collins said:
Richard Heathfield wrote:
>Keith Thompson said:
>>>It also compiles
without error with "gcc -ansi -pedantic" if I remove the "//" comments
and move a few object declarations.


That, in my view, is the author's job, not yours or mine. (And it shows
that the C99isms have been adopted gratuitously, presumably to make the
code less portable. Why anyone should wish to do this is beyond me.)
Oh no, the sky is falling,
Yes, it's in free fall, just like the rest of the planet. If this bothers
you, find a planet with less atmosphere. :-)

someone has posted code using some C99 features.
....which is fine, as long as they don't expect anyone else to be able to
compile it on a conforming implementation.

Look, if there were some compelling reason for using C99 features, okay,
fair enough: "sorry for leaving Richard H (and most of the conforming
world) behind but these C99 features are just too useful to ignore, and if
that means a portability loss, so be it". But that does not appear to be
the case here.

This is not about C90 vs C99. This is about "works everywhere" vs "works
almost nowhere, unless you use a non-conforming compiler".

--
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 15 '06 #34

P: n/a
Ian Collins <ia******@hotmail.comwrites:
Richard Heathfield wrote:
>Keith Thompson said:
>>>It also compiles
without error with "gcc -ansi -pedantic" if I remove the "//" comments
and move a few object declarations.


That, in my view, is the author's job, not yours or mine. (And it shows that
the C99isms have been adopted gratuitously, presumably to make the code
less portable. Why anyone should wish to do this is beyond me.)
Oh no, the sky is falling, someone has posted code using some C99 features.
The sooner people adopt the features which are generally supported the
better IMO ... far less porting to do further down the line :-;

Especially nice structural enhancements which improve code readability
and localization such as variable declarations at point of use.

Oct 15 '06 #35

P: n/a
Richard Heathfield <in*****@invalid.invalidwrites:
Ian Collins said:
>Richard Heathfield wrote:
>>Keith Thompson said:

It also compiles
without error with "gcc -ansi -pedantic" if I remove the "//" comments
and move a few object declarations.
That, in my view, is the author's job, not yours or mine. (And it shows
that the C99isms have been adopted gratuitously, presumably to make the
code less portable. Why anyone should wish to do this is beyond me.)
Oh no, the sky is falling,

Yes, it's in free fall, just like the rest of the planet. If this bothers
you, find a planet with less atmosphere. :-)

>someone has posted code using some C99 features.

...which is fine, as long as they don't expect anyone else to be able to
compile it on a conforming implementation.

Look, if there were some compelling reason for using C99 features, okay,
fair enough: "sorry for leaving Richard H (and most of the conforming
world) behind but these C99 features are just too useful to ignore, and if
that means a portability loss, so be it". But that does not appear to be
the case here.

This is not about C90 vs C99. This is about "works everywhere" vs "works
almost nowhere, unless you use a non-conforming compiler".
But since gcc supports a subset, and a useful subset, its hardly "almost
nowhere" is it?

And this is c.l.c not c.s.c
Oct 15 '06 #36

P: n/a
Richard Heathfield wrote:
Ian Collins said:
>>Richard Heathfield wrote:
>>>Keith Thompson said:

It also compiles
without error with "gcc -ansi -pedantic" if I remove the "//" comments
and move a few object declarations.

That, in my view, is the author's job, not yours or mine. (And it shows
that the C99isms have been adopted gratuitously, presumably to make the
code less portable. Why anyone should wish to do this is beyond me.)

Oh no, the sky is falling,

Yes, it's in free fall, just like the rest of the planet. If this bothers
you, find a planet with less atmosphere. :-)
With yes, relative to, only when Jacob posts C99 :)

I thought your original repose was a little melodramatic, considering
C99 is (a) standard C, the topic of this group.
>
>>someone has posted code using some C99 features.

....which is fine, as long as they don't expect anyone else to be able to
compile it on a conforming implementation.

Look, if there were some compelling reason for using C99 features, okay,
fair enough: "sorry for leaving Richard H (and most of the conforming
world) behind but these C99 features are just too useful to ignore, and if
that means a portability loss, so be it". But that does not appear to be
the case here.

This is not about C90 vs C99. This is about "works everywhere" vs "works
almost nowhere, unless you use a non-conforming compiler".
Which will never happen with C99 unless people (want to) use it.

Admittedly I'm biased, my platform's (POSIX) APIs use C99 features and
my stuff tends to be platform specific.

--
Ian Collins.
Oct 15 '06 #37

P: n/a
Richard said:
Richard Heathfield <in*****@invalid.invalidwrites:
<snip>
>Look, if there were some compelling reason for using C99 features, okay,
fair enough: "sorry for leaving Richard H (and most of the conforming
world) behind but these C99 features are just too useful to ignore, and
if that means a portability loss, so be it". But that does not appear to
be the case here.

This is not about C90 vs C99. This is about "works everywhere" vs "works
almost nowhere, unless you use a non-conforming compiler".

But since gcc supports a subset, and a useful subset, its hardly "almost
nowhere" is it?
When I invoke my gcc implementation in conforming mode, it (correctly)
diagnoses single-line comments, mixed code/decls, etc. If you are asking me
to turn off conforming mode, the answer is "No".

--
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 15 '06 #38

P: n/a
Richard Heathfield <in*****@invalid.invalidwrites:
Richard said:
>Richard Heathfield <in*****@invalid.invalidwrites:
<snip>
>>Look, if there were some compelling reason for using C99 features, okay,
fair enough: "sorry for leaving Richard H (and most of the conforming
world) behind but these C99 features are just too useful to ignore, and
if that means a portability loss, so be it". But that does not appear to
be the case here.

This is not about C90 vs C99. This is about "works everywhere" vs "works
almost nowhere, unless you use a non-conforming compiler".

But since gcc supports a subset, and a useful subset, its hardly "almost
nowhere" is it?

When I invoke my gcc implementation in conforming mode, it (correctly)
diagnoses single-line comments, mixed code/decls, etc. If you are asking me
to turn off conforming mode, the answer is "No".
Which conforming mode?

I have the following command line options: Pretty strict it is too.

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

Nothing particularly evil. OK, we know our target OS.

These features don't suddenly make it weaker C code - this is
comp.lang.c and C99 is the C language too. Like it, or more probably in
your case, not.

Oct 15 '06 #39

P: n/a
Ian Collins said:
I thought your original repose was a little melodramatic, considering
C99 is (a) standard C, the topic of this group.
Well, I suppose it was, but it wasn't intended to be. (Can melodrama be
accidental? I don't know.) Anyway, the point is this: that, quite often, 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.

And that's what I did this time. 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.
>This is not about C90 vs C99. This is about "works everywhere" vs "works
almost nowhere, unless you use a non-conforming compiler".
Which will never happen with C99 unless people (want to) use it.
I'll be happy to use it when it arrives (everywhere or at least nearly
everywhere), but not before.
Admittedly I'm biased, my platform's (POSIX) APIs use C99 features and
my stuff tends to be platform specific.
Which explains your point of view nicely. And it's a perfectly valid one.

My stuff tends to be platform-independent (as far as it can be). Which
explains mine. And it, too, is perfectly valid.

--
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 15 '06 #40

P: n/a
Richard said:
Richard Heathfield <in*****@invalid.invalidwrites:
>Richard said:
>>Richard Heathfield <in*****@invalid.invalidwrites:
<snip>
>>>Look, if there were some compelling reason for using C99 features,
okay, fair enough: "sorry for leaving Richard H (and most of the
conforming world) behind but these C99 features are just too useful to
ignore, and if that means a portability loss, so be it". But that does
not appear to be the case here.

This is not about C90 vs C99. This is about "works everywhere" vs
"works almost nowhere, unless you use a non-conforming compiler".

But since gcc supports a subset, and a useful subset, its hardly "almost
nowhere" is it?

When I invoke my gcc implementation in conforming mode, it (correctly)
diagnoses single-line comments, mixed code/decls, etc. If you are asking
me to turn off conforming mode, the answer is "No".

Which conforming mode?
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.

FYI my command line switches to gcc are:

CFLAGS=-W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-Wno-conversion -ffloat-store -O2
Nothing particularly evil. OK, we know our target OS.

These features don't suddenly make it weaker C code - this is
comp.lang.c and C99 is the C language too.
Yes, but where are the compilers?
Like it, or more probably in your case, not.
I'm not against C99. I'm against non-portability. But wait...!

--
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 15 '06 #41

P: n/a
Richard Heathfield <in*****@invalid.invalidwrites:

My stuff tends to be platform-independent (as far as it can be). Which
explains mine. And it, too, is perfectly valid.
Yes. Agreed. But it doesn't make it valid for you to criticise someone whose
target compiler does support C99 and who wishes to use those features.

And that was why there were a few "err, hang on there" replies.

Oct 15 '06 #42

P: n/a
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?
>Like it, or more probably in your case, not.

I'm not against C99. I'm against non-portability. But wait...!
Not all C code is intended to be portable. And C99 is a developing
standard ....

Oct 15 '06 #43

P: n/a
Richard said:
Richard Heathfield <in*****@invalid.invalidwrites:

>My stuff tends to be platform-independent (as far as it can be). Which
explains mine. And it, too, is perfectly valid.

Yes. Agreed. But it doesn't make it valid for you to criticise someone
whose target compiler does support C99
It does? What makes you think so? As far as I'm aware, Mr Navia uses
lcc-win32 and, sometimes, gcc. Neither of these is C99-conforming.

--
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 15 '06 #44

P: n/a
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. I thought I mentioned that?
>>Like it, or more probably in your case, not.

I'm not against C99. I'm against non-portability. But wait...!

Not all C code is intended to be portable.
Certainly true. That is why we have platform-specific newsgroups, such as
comp.os.ms-windows.programmer.win32, comp.unix.programmer,
comp.os.msdos.programmer, and even comp.compilers.lcc - and
platform-specific code can be profitably discussed in such newsgroups.
And C99 is a developing standard ....
If that is so, then it makes it all the harder to write conforming code in
it, let alone get that code to work as portably as C90 code.

--
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 15 '06 #45

P: n/a
Richard Heathfield wrote:
>>>
foo.c:12: parse error before `/'
foo.c:17: stray '\' in program
[51 lines deleted]
>>make: *** [foo.o] Error 1

<shrugI figured it had to be something like that. So - does anyone have a
conforming C99 compiler that we can use to test Mr Navia's code? No? Oh
well.
You're just trolling now. This is about as useful as asking
why someone is left-shifting cout.

Besides, you have admitted on other threads that it's OK for a
C90 compiler to have one or two conformance problems in deep
dark corners that nobody uses, as long as it compiles 'normal'
conforming programs correctly.

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.

Oct 15 '06 #46

P: n/a
Old Wolf said:
Richard Heathfield wrote:
>>>>
foo.c:12: parse error before `/'
foo.c:17: stray '\' in program
[51 lines deleted]
make: *** [foo.o] Error 1

<shrugI figured it had to be something like that. So - does anyone have
a conforming C99 compiler that we can use to test Mr Navia's code? No? Oh
well.

You're just trolling now.
Nope.
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.

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. He is perfectly within his rights to do that and still remain
topical. Nevertheless, making code gratuitously difficult to compile is not
a useful strategy. It's akin to posting obfuscated code (with which a
compiler will have no trouble at all, but to which clcers will still object
as it is gratuitously difficult to read - even though it might well be a
strictly conforming C90 program!).
Besides, you have admitted on other threads that it's OK for a
C90 compiler to have one or two conformance problems in deep
dark corners that nobody uses, as long as it compiles 'normal'
conforming programs correctly.
I'm not saying I approve of such conformance problems, of course, but yes,
we live with what we've got. What we *haven't* got is a plethora of
compilers that even /claim/ conformance to C99. We have a small handful, of
which gcc is not one.
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?

--
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 15 '06 #47

P: n/a
Richard <rg****@gmail.comwrites:
Richard Heathfield <in*****@invalid.invalidwrites:
[...]
>When I invoke my gcc implementation in conforming mode, it (correctly)
diagnoses single-line comments, mixed code/decls, etc. If you are asking me
to turn off conforming mode, the answer is "No".

Which conforming mode?

I have the following command line options: Pretty strict it is too.

CFLAGS=-std=c99 -pedantic-errors -Wall -pthread -g $(DEBUGFLAGS)
That does not conform to any standard. It fails to diagnose some
things that are syntax errors in C90, and fails to implement some
features of C99.

--
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 #48

P: n/a
In article <45***********************@news.orange.frjacob navia <ja***@jacob.remcomp.frwrites:
Jean-Marc Bourguet wrote:
....
>>That doesn't mean such machines don't exist. I've spent several years
working on such machines. Look up "EBCDIC" in Google.
<snip>

Also BCD, as used on a 14xx series system. (came before "EBCDIC") :-)
BCD is worse, not only there are not contiguous, they aren't even in order.

Well, EBCDIC was a 7 bit code, used for punched cards. The eighth bit
was there to signal the card reader that a character was in that column.
Very wrong. EBCDIC is an 8 bit code, and never has been a 7-bit code. It
was not only used for punched cards, but also on papertape, internally,
and whatever (note the 'IC': Internal Code'). (Although I have never seen
punched card equipment that actually did do full EBCDIC.)
Using only 7 bits, the codes are continuous.
Wrong. There are gaps between 'I' and 'J', and between 'R' and 'S'.
The closing curly brace is in the order between 'I' and 'J' and the
backslash between 'R' and 'S'. When you go to 7 bits (and hence do
use BCD instead of EBCDIC), you will find symbols like '-', '/', '+',
'&' and quite some others (depending on the version of BCD used) in
the range of letters.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Oct 16 '06 #49

P: n/a
Richard Heathfield <in*****@invalid.invalidwrites:
Ian Collins said:
>I thought your original repose was a little melodramatic, considering
C99 is (a) standard C, the topic of this group.

Well, I suppose it was, but it wasn't intended to be. (Can melodrama be
accidental? I don't know.) Anyway, the point is this: that, quite often, 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.

And that's what I did this time. 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.

--
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 #50

121 Replies

This discussion thread is closed

Replies have been disabled for this discussion.