A simple parser

R

Richard Heathfield

Richard said:
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...!
 
R

Richard

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

Richard

Richard Heathfield said:
Yes, but where are the compilers?

Err, for the C99 features I use (primarily localised declarations),
gcc. I thought I mentioned that?
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 ....
 
R

Richard Heathfield

Richard said:
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.
 
R

Richard Heathfield

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. I thought I mentioned that?
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.
 
O

Old Wolf

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

<shrug> I 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.
 
R

Richard Heathfield

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

<shrug> I 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?
 
K

Keith Thompson

Richard said:
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.
 
D

Dik T. Winter

> Jean-Marc Bourguet wrote: ....
>
> 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.
 
K

Keith Thompson

Richard Heathfield said:
Ian Collins said:

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

Keith Thompson

Richard said:
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.
 
O

Old Wolf

Richard said:
Old Wolf said:


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

Keith Thompson

Richard Heathfield said:
Keith Thompson said:

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

Richard Heathfield

Old Wolf said:
Richard said:
Old Wolf said:


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

Richard Heathfield

Keith Thompson said:

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

Tak-Shing Chan

[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
 
R

Richard Heathfield

Tak-Shing Chan said:
[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.
 
R

Richard

Richard Heathfield said:
Keith Thompson said:



Quite so.


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

Richard Heathfield

Richard said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

How to remove // comments 100
// comments 35
Text processing 29
Serial port 5
Command Line Arguments 0
Deleting first N lines from a text file 26
Working with files 1
Taking a stab at getline 40

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top