lcc-win32 conformance question

[teapot]

If I compile this program

int main(void)
{
return 0; // foo bar baz
}

with

"lc -A -ansi89 foo.c"

(minus the quotes), no diagnostic is produced; but isn't this style of
comment illegal in C89 and thus this piece of code should be invalid?

How standards conformant is (unnamed compiler)?

 

[Ian Collins]

If I compile this program

int main(void)
{
return 0; // foo bar baz
}

with

"lc -A -ansi89 foo.c"

(minus the quotes), no diagnostic is produced; but isn't this style of
comment illegal in C89 and thus this piece of code should be invalid?

How standards conformant is (unnamed compiler)?

Why are you asking on a C++ group?

 

[Ian Collins]

Why are you asking on a C++ group?

Oops, I buggered that up, wrong group open...

 

[Bartc]

If I compile this program

int main(void)
{
return 0; // foo bar baz
}

with

"lc -A -ansi89 foo.c"

(minus the quotes), no diagnostic is produced; but isn't this style of
comment illegal in C89 and thus this piece of code should be invalid?

How standards conformant is (unnamed compiler)?

You mean, the unnamed compiler called lcc-win32?

Well, I couldn't get an error message from it. Neither from using
DigitalMars DMC -A.

GCC of course complained, but then with it's 10000 options it would be odd
if it missed that one.

Sorry I didn't have any more command-line compilers to try..

I guess some are strictly conformant are some aren't. Perhaps there should
be a certificate issued to conformant ones to stop you absentmindedly
sneaking in a // comment or two!

 

[Ben Bacarisse]

If I compile this program

int main(void)
{
return 0; // foo bar baz
}

with

"lc -A -ansi89 foo.c"

(minus the quotes), no diagnostic is produced; but isn't this style of
comment illegal in C89 and thus this piece of code should be invalid?

If the compiler claims conformance to the obvious standard when passed
that flag then it is in error. Of course, just passing flag means
nothing. Does the documentation claim conformance to C90 (= ANSI C89)?

How standards conformant is (unnamed compiler)?

Do you mean lcc-win32? If so, I have found problems with compound
literals, VLA parameters, complex numbers and designated initialisers
so some of the C99 parts are a bit rough round the edges. There have
been a few other reports of conformance issues, but they may well have
been fixed. For example, it used to consider long * and int * to be
compatible types.

It is probably fair to say the standards conformance is not a top
priority for that compiler.

 

[jacob navia]

Why are you asking on a C++ group?

Because pissing lcc-win is his favorite spot, like my cat
that pisses everywhere even in my computer!

 

[santosh]

Because pissing lcc-win is his favorite spot, like my cat
that pisses everywhere even in my computer!

In any case is what the OP claims true? Are there command-line switches
to get a diagnostic for C++ style comments when compiler in strict C90
mode?

PS. I think you should cool down a little and not give these anonymous
posters much weightage (except if they do uncover a real issue in
lcc-win). Even your prose has started suffering.

 

[Serve Laurijssen]

If I compile this program

int main(void)
{
return 0; // foo bar baz
}

with

"lc -A -ansi89 foo.c"

(minus the quotes), no diagnostic is produced; but isn't this style of
comment illegal in C89 and thus this piece of code should be invalid?

How standards conformant is (unnamed compiler)?

oh no it accepts C++ style comments!!
really, who cares!!

 

[santosh]

oh no it accepts C++ style comments!!
really, who cares!!

Anyone who wants to compile the same code under a strictly C90
conforming mode on another compiler which does reject C++ style
comments as syntax errors. All is well if that compiler happens to have
a switch to make it specifically accept this comment style while
retaining strict C90 conformance in all other respects, but most
compilers don't have such fine-grained control. You'll probably need to
compile the code under either C99 conformance (which in turn may not
even be available), or in some other "relaxed" mode which might accept
other non-C90 constructs that would otherwise have been diagnosed.

 

[ymuntyan]

If the compiler claims conformance to the obvious standard when passed
that flag then it is in error.

Why is it an error? A C90 compiler can reject that program,
that's clear; but why does it have to?

Yevgen

 

[ymuntyan]

In any case is what the OP claims true? Are there command-line switches
to get a diagnostic for C++ style comments when compiler in strict C90
mode?

PS. I think you should cool down a little and not give these anonymous
posters much weightage (except if they do uncover a real issue in
lcc-win). Even your prose has started suffering.

Jacob certainly should not overreact, he harms himself with
that. But you should admit that all the posters assumed
that the given issue is a non-conformance bug, yet nobody
said why it is so. Or at least nobody said that it was *not*
a conformance bug, which effectively is the same thing as
agreeing that it was (comp.lang.c - best resource for newbies,
all mistakes corrected, etc.)

Yevgen

 

[Lew Pitcher]

If I compile this program

int main(void)
{
return 0; // foo bar baz
}

with

"lc -A -ansi89 foo.c"

(minus the quotes), no diagnostic is produced; but isn't this style of
comment illegal in C89

As I understand it, there is nothing in the C89 standard that explicitly
indicates that the C++-style // comment is illegal.

However, a compliant compiler is obliged to interpret the given line
// foo bar baz
as
a division token, followed by
a division token, followed by
an identifier token, followed by
an identifier token, followed by
an identifier token, followed by
a right brace bracket
which, of course, cannot be interpreted as a semantically correct C (C89)
statement. IIRC, a diagnostic should be emitted.

and thus this piece of code should be invalid?

How standards conformant is (unnamed compiler)?

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Flash Gordon]

Why is it an error? A C90 compiler can reject that program,
that's clear; but why does it have to?

Having produced a diagnostic it is allowed to produce an executable.
However, // is a syntax error so a diagnostic is required. Arrantly none
is produced by lcc-win32 in C89 conforming mode.

I would expect this to be an easy bug for Jacob to fix, all he has to do
is check what mode the compiler is in once he has detected the // and
produce an appropriate diagnostic.

 

[Ben Bacarisse]

Why is it an error? A C90 compiler can reject that program,
that's clear; but why does it have to?

Because it contains a syntax error. It need not reject it, but a
diagnostic is required. The "error" is that the compiler is silent.

As I said (in snipped text) I have no idea if the -ansi89 flag does
what one might guess it does. As far as I can see lcc-win32 accepts
all kinds of stuff that require a diagnostic when seen by a C90
compiler. Unless someone says what the -ansi89 flag *should* do we
must be silent.

 

[Ben Bacarisse]

As I understand it, there is nothing in the C89 standard that explicitly
indicates that the C++-style // comment is illegal.

The syntax does. // is either a syntax error or the start of something
like 1//* divide? */2 which must be taken as an arithmetic
expression. I can't see what else it could be.

However, a compliant compiler is obliged to interpret the given line
// foo bar baz
as
a division token, followed by
a division token, followed by
an identifier token, followed by
an identifier token, followed by
an identifier token, followed by
a right brace bracket
which, of course, cannot be interpreted as a semantically correct C (C89)
statement. IIRC, a diagnostic should be emitted.

Yes, the cited example is just a syntax error, but we have no idea
what, if any, claims are made about the -ansi89 flag. Maybe it
implements some parts of ANSI 89 C? Unless that author says what is
should do, how can we anyone complain about what the compiler does?

 

[ymuntyan]

Because it contains a syntax error. It need not reject it, but a
diagnostic is required. The "error" is that the compiler is silent.

Actually what I wanted was the reference to the standard,
and I found it (surprisingly, it's where "diagnostic"is
defined). I have always thought that syntax extensions are
allowed, that's why I insisted on "why?". E.g. I was sure
that gcc doesn't have to warn about __attribute__ even in
conforming mode. Now I have a question about conformance
of one unnamed compiler:

Is this unnamed compiler non-conforming?

Yevgen

 

[ymuntyan]

Actually what I wanted was the reference to the standard,
and I found it (surprisingly, it's where "diagnostic"is
defined). I have always thought that syntax extensions are
allowed, that's why I insisted on "why?". E.g. I was sure
that gcc doesn't have to warn about __attribute__ even in
conforming mode. Now I have a question about conformance
of one unnamed compiler:


__attribute__((unused)) static int a;

It seems "greater than" signs are mangled somehow,
the above should read

$$$ cat ex.i
__attribute__((unused)) static int a;
$$$ gcc -c -W -Wall -pedantic -ansi ex.i
$$$

I.e. no diagnostics is emitted when compiling
a file consisting of one line

__attribute__((unused)) static int a;

Yevgen

 

[Richard Tobin]

However, a compliant compiler is obliged to interpret the given line
// foo bar baz
as
a division token, followed by
a division token, followed by
an identifier token, followed by
an identifier token, followed by
an identifier token, followed by
a right brace bracket
which, of course, cannot be interpreted as a semantically correct C (C89)
statement.

It can't even be *parsed* as a C89 program, because it does not match
the grammar. It's a syntactic error, not a semantic one.

-- Richard

 

[Chris Torek]

Actually what I wanted was the reference to the standard,
and I found it (surprisingly, it's where "diagnostic"is
defined). I have always thought that syntax extensions are
allowed, that's why I insisted on "why?". E.g. I was sure
that gcc doesn't have to warn about __attribute__ even in
conforming mode. Now I have a question about conformance
of one unnamed compiler [which does not complain about a

translation unit consisting entirely of the one line]

__attribute__((unused)) static int a;

Is this unnamed compiler non-conforming?

Not from this example. The reason is that names prefixed with
various kinds of underscores (including single underscores followed
by uppercase, and double underscores) are reserved to the
implementation, and once you use an "implementation keyword", the
entire "contract", as it were, that the Standard provides to the
C programmer is terminated, at least in principle.

Thus, the following does not require a diagnostic:

#pragma comment !
! hi there.
static int a;

because "#pragma" can also do pretty much anything (although in
C99 there are now standardized #pragma operations). (Perhaps, as
in this case, the "#pragma" turns "!" into a comment-to-end-of-line
character. "#pragma fortran" might be used to switch to Fortran
code, which would change the syntax even more.)

This is, of course, the danger of doing anything that departs from
Standard C: the moment you abandon the standard, even for an instant,
the standard can abandon you, possibly "forever". Of course,
real, reasonable C implementations do not do so: they disable
"complete standard-ness" long enough for you to useful work, while
retaining "enough standard-ness" long enough for you to, well, do
useful work. However, for reasons both good and bad, these may
lure you into doing things that, in effect, "capture" you into
staying with that particular compiler-vendor "forever". This in
turn may be good (lets you get your work done in a reasonable way
and timely fashion, for instance) or bad (costs you a million
dollars every five minutes, for instance), or possibly both.

 

[Ben Bacarisse]

You may be right (about syntax extensions) but I doubt it. In any
case, // can't be an extension in any useful sense since

I think gcc should issue a diagnostic here in a conforming mode. What
that means is that the only way to invoke gcc in conforming mode is
to add "-D__attribute__(x)=\\" to the gcc command

OK, the smiley shows I am not entirely serious, but there is a serious
point here. The illegal __attribute__ syntax is easy to either remove
or flag as an error (as I did above) whereas adding // as an extension
is impossible to correct. Some correct programs will be rejected (for
example

int main(void) { return 1//**/2; }

) or some syntax errors will go un-remarked on.