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]

teapot wrote:

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.

[Ian Collins]

Ian Collins wrote:

teapot wrote:

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

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

--
Ian Collins.

[Bartc]

"teapot" <te*@pot.invalidwrote in message
news:19****************@aioe.org...

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

--
bartc

[Ben Bacarisse]

teapot <te*@pot.invalidwrites:

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.

--
Ben.

[jacob navia]

Ian Collins wrote:

teapot wrote:

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

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

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[santosh]

jacob navia wrote:

Ian Collins wrote:

>teapot wrote:

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

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]

"teapot" <te*@pot.invalidschreef in bericht
news:19****************@aioe.org...

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

Serve Laurijssen wrote:

>
"teapot" <te*@pot.invalidschreef in bericht
news:19****************@aioe.org...

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

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.

[CBFalconer]

Serve Laurijssen wrote:

"teapot" <te*@pot.invalidschreef in bericht

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

Anyone trying to prepare source suitable for a C90 compiler, or for
publication on a Usenet newsgroup.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Malcolm McLean]

"Serve Laurijssen" <[e-mail] in message

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

My Message Passing Interface (MPI) compiler won't accept slash slash
comments. So any portable functions including them have to be rewritten for
it.

It surprised me.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[ymuntyan]

On Apr 25, 7:17 pm, Ben Bacarisse <[e-mail]:

teapot <[e-mail]:

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.

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

Yevgen

[ymuntyan]

On Apr 26, 6:37 am, santosh <[e-mail]:

jacob navia wrote:

Ian Collins wrote:

teapot wrote:
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?

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.

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]

In comp.lang.c, teapot wrote:

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

[Ben Bacarisse]

ym******@gmail.com writes:

On Apr 25, 7:17 pm, Ben Bacarisse <[e-mail]:

>teapot <[e-mail]:

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.

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.

[Flash Gordon]

ym******@gmail.com wrote, On 26/04/08 23:37:

On Apr 25, 7:17 pm, Ben Bacarisse <[e-mail]:

>teapot <[e-mail]:

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

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

[Ben Bacarisse]

Lew Pitcher <lp******@teksavvy.comwrites:

In comp.lang.c, teapot wrote:

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

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?

--
Ben.

[ymuntyan]

On Apr 26, 6:50 pm, Ben Bacarisse <[e-mail]:

[e-mail] writes:

On Apr 25, 7:17 pm, Ben Bacarisse <[e-mail]:

teapot <[e-mail]:
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.

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.

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:

>>cat ex.i

__attribute__((unused)) static int a;

>>gcc -c -W -Wall -pedantic -ansi ex.i

Is this unnamed compiler non-conforming?

Yevgen

[ymuntyan]

On Apr 26, 7:07 pm, [e-mail] wrote:

On Apr 26, 6:50 pm, Ben Bacarisse <[e-mail]:

[e-mail] writes:

On Apr 25, 7:17 pm, Ben Bacarisse <[e-mail]:
>teapot <[e-mail]:
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.

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.

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:

>cat ex.i

__attribute__((unused)) static int a;

>gcc -c -W -Wall -pedantic -ansi ex.i

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]

In article <c8**************************@TEKSAVVY.COM-Free>,
Lew Pitcher <lp******@teksavvy.comwrote:

>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
--
:wq

[Chris Torek]

In article <96**********************************@p25g2000hsf. googlegroups.com>
<ym******@gmail.comwrote:

>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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: gmail (figure it out) http://web.torek.net/torek/index.html

[Ben Bacarisse]

ym******@gmail.com writes:

On Apr 26, 7:07 pm, [e-mail] wrote:

>On Apr 26, 6:50 pm, Ben Bacarisse <[e-mail]:

<snip>

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,

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

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

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.

--
Ben.

[Ben Bacarisse]

Chris Torek <no****@torek.netwrites:

In article <96**********************************@p25g2000hsf. googlegroups.com>
<ym******@gmail.comwrote:

<on the correctness of gcc silently accepting:>

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

That is an interesting (and new to me) viewpoint. It means that the
standard does require that a conforming implementation should be able
to be told to reject all extensions. Obviously an implementation may
offer this help, but I can't be sure that turning on all the standards
flags will do it.

Allowing all bets to be off after a #pragma is not so worrying to me --
I can grep for those. I can't search for examples of __?words that are
not "standard" with anything like the same ease.

--
Ben.

[Chris Torek]

>Chris Torek <no****@torek.netwrites:

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

(Incidentally, I am not sure whether one can at least expect
the file *up to that point* to respect C syntax.)

In article <87************@bsb.me.uk>,
Ben Bacarisse <be********@bsb.me.ukwrote:

>That is an interesting (and new to me) viewpoint. It means that the
standard does require that a conforming implementation should be able
to be told to reject all extensions. Obviously an implementation may
offer this help, but I can't be sure that turning on all the standards
flags will do it.

Allowing all bets to be off after a #pragma is not so worrying to me --
I can grep for those. I can't search for examples of __?words that are
not "standard" with anything like the same ease.

Indeed. However, it is worse (and yet better) than that. Consider,
for instance, the following:

#include "my.h"

This *looks* inocuous enough, until we find that my.h starts with:

#include <system-magic.h>

which, through a chain of 97812 other "#include"s, eventually does:

#pragma lisp

so everything after including "my.h" is Lisp!

This problem never actually occurs in practice, because people are
not quite that crazy. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: gmail (figure it out) http://web.torek.net/torek/index.html

[CBFalconer]

ym******@gmail.com wrote:

Ben Bacarisse <[e-mail]:

>teapot <[e-mail]:

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

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

Because the // is a syntax error.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Richard Heathfield]

ym******@gmail.com said:

<snip>

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.

Are you claiming that failure to issue a required diagnostic message for a
syntax error is somehow not a conformance problem?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[ymuntyan]

On Apr 26, 8:31 pm, Chris Torek <[e-mail]:

In article <[e-mail]<ymunt... @gmail.comwrote:

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". :-)

I believe I understand what you're saying, yet I don't
quite understand where that fine line between "syntax
error" and "not a syntax error" is drawn. Namely, why
is // a deviation from the C syntax which must be diagnosed,
while __attribute__ isn't? Or why __attribute__ is fine
while 234i literal isn't?

So, the question is: where exactly does the standard say
that implementation is free to use any __-prefixed identifier
as a magic word which may completely change semantics of the
program? It does say that such identifiers are reserved,
yet they still are identifiers.

Yevgen

[ymuntyan]

On Apr 27, 12:09 am, Richard Heathfield <[e-mail]:

[e-mail] said:

<snip>

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.

Are you claiming that failure to issue a required diagnostic message for a
syntax error is somehow not a conformance problem?

No, and I have not claimed that. I didn't know that diagnostic
was required in that case, that's true. Yet I didn't even claim
it wasn't required.

Yevgen

[Ian Collins]

ym******@gmail.com wrote:

On Apr 26, 8:31 pm, Chris Torek <[e-mail]:

>>
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". :-)

I believe I understand what you're saying, yet I don't
quite understand where that fine line between "syntax
error" and "not a syntax error" is drawn. Namely, why
is // a deviation from the C syntax which must be diagnosed,
while __attribute__ isn't? Or why __attribute__ is fine
while 234i literal isn't?

__attribute__ is in the implementation's namespace, so the
implementation is free to treat it how is sees fit. 234i is not.

So, the question is: where exactly does the standard say
that implementation is free to use any __-prefixed identifier
as a magic word which may completely change semantics of the
program? It does say that such identifiers are reserved,
yet they still are identifiers.

Reserved, for the implementation. So it can do what it likes with them.

--
Ian Collins.

[ymuntyan]

On Apr 27, 12:38 am, Ian Collins <[e-mail]:

[e-mail] wrote:

On Apr 26, 8:31 pm, Chris Torek <[e-mail]:

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". :-)

I believe I understand what you're saying, yet I don't
quite understand where that fine line between "syntax
error" and "not a syntax error" is drawn. Namely, why
is // a deviation from the C syntax which must be diagnosed,
while __attribute__ isn't? Or why __attribute__ is fine
while 234i literal isn't?

__attribute__ is in the implementation's namespace, so the
implementation is free to treat it how is sees fit. 234i is not.

"namespace" here is not the standard term, so if you
mean "it's magic", then I already got that ;)
So, 234i is not C, "int __attribute__((something)) something;"
isn't C either, both are invalid according to the grammar.
The former is not magical, the latter is. Does "reserved" really
clearly imply this magic/not-magic distinction? I do think
it's a good rule, "__ =anything may happen", but it doesn't
seem to be what standard really say, or is it?

So, the question is: where exactly does the standard say
that implementation is free to use any __-prefixed identifier
as a magic word which may completely change semantics of the
program? It does say that such identifiers are reserved,
yet they still are identifiers.

Reserved, for the implementation. So it can do what it likes with them.

Yevgen

[Richard Heathfield]

ym******@gmail.com said:

On Apr 27, 12:09 am, Richard Heathfield <[e-mail]:

>[e-mail] said:

<snip>

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.

Are you claiming that failure to issue a required diagnostic message for
a syntax error is somehow not a conformance problem?

No, and I have not claimed that. I didn't know that diagnostic
was required in that case, that's true.

Thank you for explaining this. I was under the impression that you knew.

Yet I didn't even claim it wasn't required.

No, you didn't claim that. I didn't realise you didn't know the situation
pertaining to the diagnostic obligations of conforming implementations.
Now that I do realise this, I can answer your above point more
pertinently:

I would guess that all the posters who knew that the given issue is to do
with non-conformance (and why) assumed that everyone else in the
discussion also knew that it was to do with non-conformance (and why).

And *that* assumption (i.e. the assumption that everyone else knew) now
appears to be ill-founded.

So: to clarify, the appearance of a // in a C90 program is either:

(a) part of a string literal " like // this "; or
(b) part of a comment /* like // this */; or
(c) a division followed immediately by a comment like//*this*/that; or
(d) a syntax error.

I think that covers all the possibilities.

As you can see, it isn't *necessarily* a syntax error - but that is the
most likely of the four possibilities when someone has been using // for
comment syntax without malice aforethought. And syntax errors *must* be
diagnosed; the Standard requires it. So if a compiler finds a // that it
can't twist into some syntactically legitimate interpretation (e.g. (a)
through (c) above), it must issue a diagnostic message.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Ben Bacarisse wrote:

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

All the bugs you mentioned were fixed as quickly as I could.

That is not, of course, TOP PRIORITY. Some bugs were
fixed in less than a few hours. But that is NOT TOP PRIORITY.

What, then, would be TOP PRIORITY?

A few seconds?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Flash Gordon]

Richard Heathfield wrote, On 27/04/08 07:13:

ym******@gmail.com said:

>On Apr 27, 12:09 am, Richard Heathfield <[e-mail]:

>>[e-mail] said:

<snip>

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.
Are you claiming that failure to issue a required diagnostic message for
a syntax error is somehow not a conformance problem?

No, and I have not claimed that. I didn't know that diagnostic
was required in that case, that's true.

Thank you for explaining this. I was under the impression that you knew.

>Yet I didn't even claim it wasn't required.

No, you didn't claim that. I didn't realise you didn't know the situation
pertaining to the diagnostic obligations of conforming implementations.
Now that I do realise this, I can answer your above point more
pertinently:

I would guess that all the posters who knew that the given issue is to do
with non-conformance (and why) assumed that everyone else in the
discussion also knew that it was to do with non-conformance (and why).

And *that* assumption (i.e. the assumption that everyone else knew) now
appears to be ill-founded.

So: to clarify, the appearance of a // in a C90 program is either:

(a) part of a string literal " like // this "; or
(b) part of a comment /* like // this */; or
(c) a division followed immediately by a comment like//*this*/that; or
(d) a syntax error.

I think that covers all the possibilities.

You missed multi-byite character constants like this '//' ;-)

As you can see, it isn't *necessarily* a syntax error - but that is the
most likely of the four possibilities when someone has been using // for
comment syntax without malice aforethought. And syntax errors *must* be
diagnosed; the Standard requires it. So if a compiler finds a // that it
can't twist into some syntactically legitimate interpretation (e.g. (a)
through (c) above), it must issue a diagnostic message.

The example given, of course, clearly did not fit in to any of the
legitimate interpretations.
--
Flash Gordon

[Flash Gordon]

ym******@gmail.com wrote, On 27/04/08 07:07:

On Apr 27, 12:38 am, Ian Collins <[e-mail]:

>[e-mail] wrote:

>>On Apr 26, 8:31 pm, Chris Torek <[e-mail]:
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". :-)
I believe I understand what you're saying, yet I don't
quite understand where that fine line between "syntax
error" and "not a syntax error" is drawn. Namely, why
is // a deviation from the C syntax which must be diagnosed,
while __attribute__ isn't? Or why __attribute__ is fine
while 234i literal isn't?

__attribute__ is in the implementation's namespace, so the
implementation is free to treat it how is sees fit. 234i is not.

"namespace" here is not the standard term, so if you
mean "it's magic", then I already got that ;)

"namespace" is not a standard term, but "name spaces" is a standard term,

So, 234i is not C, "int __attribute__((something)) something;"
isn't C either, both are invalid according to the grammar.

Not necessarily. Consider the following TU which uses the same syntax:

#define attribute(a)
int attribute((something)) something;

So whether it is valid according to the grammar depends on the
definition of __attribute__. Note that the implementation is
specifically allowed to have predefined macros starting with a double
underscore. Note also that predefined macros are not subject to
#undef/#define according to the standard.

The former is not magical, the latter is. Does "reserved" really
clearly imply this magic/not-magic distinction? I do think
it's a good rule, "__ =anything may happen", but it doesn't
seem to be what standard really say, or is it?

<snip>

It is an interesting point. Conforming implementations are explicitly
allowed to have extensions provided they do not affect the behaviour of
any strictly conforming program, and no strictly conforming program can
use identifiers starting with __ except where they are explicitly
defined by the standard.
--
Flash Gordon

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:
[...]

So: to clarify, the appearance of a // in a C90 program is either:

(a) part of a string literal " like // this "; or
(b) part of a comment /* like // this */; or
(c) a division followed immediately by a comment like//*this*/that; or
(d) a syntax error.

I think that covers all the possibilities.

Not quite.

(e) part of a multi-character character constant, such as '//' or
L'//'; or
(f) part of a header name, such as #include <foo//bar.hor
#include "foo//bar.h" (no, the latter is not actually a string
literal)
(g) part of a sequence of preprocessor tokens that are discarded, as in:
#define IGNORE(x) /* nothing */
IGNORE(//)
or
#if 0
// no, this isn't a comment
#endif
; or
(h) part of a #error directive (though this causes the translation
unit to be rejected); or
(i) part of an implementation-defined #pragma directive.

I *think* that covers all the cases, but I wouldn't swear to it.

As you can see, it isn't *necessarily* a syntax error - but that is the
most likely of the four possibilities when someone has been using // for
comment syntax without malice aforethought. And syntax errors *must* be
diagnosed; the Standard requires it. So if a compiler finds a // that it
can't twist into some syntactically legitimate interpretation (e.g. (a)
through (c) above), it must issue a diagnostic message.

Yes. The requirement is stated in C90 5.1.1.3:

A conforming implementation shall produce at least one diagnostic
message (identified in an implementation-defined manner) for every
translation unit that contains a violation of any syntax rule or
constraint. Diagnostic messages need not be produced in other
circumstances.

(C99 has a similar rule, also in 5.1.1.3, though there's some
additional wording; of course, C99's syntax rules permit // comments.)

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Ian Collins <ia******@hotmail.comwrites:

ym******@gmail.com wrote:

>On Apr 26, 8:31 pm, Chris Torek <[e-mail]:

>>>
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". :-)

I believe I understand what you're saying, yet I don't
quite understand where that fine line between "syntax
error" and "not a syntax error" is drawn. Namely, why
is // a deviation from the C syntax which must be diagnosed,
while __attribute__ isn't? Or why __attribute__ is fine
while 234i literal isn't?

__attribute__ is in the implementation's namespace, so the
implementation is free to treat it how is sees fit. 234i is not.

Yes, but ...

__attribute__ is an identifier, a valid token, so by itself it's not
necessarily a syntax error. 234i is not a valid token.

>So, the question is: where exactly does the standard say
that implementation is free to use any __-prefixed identifier
as a magic word which may completely change semantics of the
program? It does say that such identifiers are reserved,
yet they still are identifiers.

Reserved, for the implementation. So it can do what it likes with them.

Within limits.

I'll quote from the C99 standard, because my copy of it is easier to
copy-and-paste from than my copy of the C90 standard. C90 has similar
rules.

C99 4p6:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.

with a footnote:

This implies that a conforming implementation reserves no
identifiers other than those explicitly reserved in this
International Standard.

For example, since the identifier __attribute__ is reserved to the
implementation, no strictly conforming program may use it; therefore,
a conforming implementation may provide an extension that affects only
programs that use the identifier __attribute__.

But must the implementation still issue a diagnostic if the use of an
extension violates a constraint or syntax rule? In my opinion, the
answer is yes; the standard permits extensions, but that doesn't
override the requirement to issue a diagnostic. Doug Gwyn, a member
of the C standard committee, has expressed the same opinion over on
comp.std.c.

So, a conforming C90 implementation may allow // comments as an
extension (as long as a division symbol immediately followed by a
/*comment*/ is *not* treated as a // comment), *but* it must still
issue at least one diagnostic for any translation unit that uses a //
comment. It doesn't have to reject such a translation unit; the
standard's only requirement to reject a translation unit is for the
#error directive. The diagnostic could be "Thank you for using this
extension, and have a nice day".

And, of course, it needn't issue the diagnostic in a non-conforming
mode; after all, the standard cannot possibly impose *any*
requirements on an implementation that doesn't claim to conform to it.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Keith Thompson <ks***@mib.orgwrites:

Richard Heathfield <rj*@see.sig.invalidwrites:
[...]

>So: to clarify, the appearance of a // in a C90 program is either:

(a) part of a string literal " like // this "; or
(b) part of a comment /* like // this */; or
(c) a division followed immediately by a comment like//*this*/that; or
(d) a syntax error.

I think that covers all the possibilities.

Not quite.

(e) part of a multi-character character constant, such as '//' or
L'//'; or
(f) part of a header name, such as #include <foo//bar.hor
#include "foo//bar.h" (no, the latter is not actually a string
literal)
(g) part of a sequence of preprocessor tokens that are discarded, as in:
#define IGNORE(x) /* nothing */
IGNORE(//)
or
#if 0
// no, this isn't a comment
#endif
; or
(h) part of a #error directive (though this causes the translation
unit to be rejected); or
(i) part of an implementation-defined #pragma directive.

I *think* that covers all the cases, but I wouldn't swear to it.

[...]

(j) a comment followed immediately by a division like/*this*//that
(the reverse of case (c)).

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[ymuntyan]

On Apr 27, 4:18 am, Flash Gordon <[e-mail]:

[e-mail] wrote, On 27/04/08 07:07:

On Apr 27, 12:38 am, Ian Collins <[e-mail]:

[e-mail] wrote:
On Apr 26, 8:31 pm, Chris Torek <[e-mail]:
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". :-)
I believe I understand what you're saying, yet I don't
quite understand where that fine line between "syntax
error" and "not a syntax error" is drawn. Namely, why
is // a deviation from the C syntax which must be diagnosed,
while __attribute__ isn't? Or why __attribute__ is fine
while 234i literal isn't?
__attribute__ is in the implementation's namespace, so the
implementation is free to treat it how is sees fit. 234i is not.

"namespace" here is not the standard term, so if you
mean "it's magic", then I already got that ;)

"namespace" is not a standard term, but "name spaces" is a standard term,

Which isn't what was '"namespace" here'.

So, 234i is not C, "int __attribute__((something)) something;"
isn't C either, both are invalid according to the grammar.

Not necessarily. Consider the following TU which uses the same syntax:

#define attribute(a)
int attribute((something)) something;

So whether it is valid according to the grammar depends on the
definition of __attribute__. Note that the implementation is
specifically allowed to have predefined macros starting with a double
underscore. Note also that predefined macros are not subject to
#undef/#define according to the standard.

Right. But I fed file.i to gcc for exactly that reason -
__attribute__ is part of gcc grammar, and it won't warn
about it. I do realize now that it doesn't matter.

>

The former is not magical, the latter is. Does "reserved" really
clearly imply this magic/not-magic distinction? I do think
it's a good rule, "__ =anything may happen", but it doesn't
seem to be what standard really say, or is it?

<snip>

It is an interesting point. Conforming implementations are explicitly
allowed to have extensions provided they do not affect the behaviour of
any strictly conforming program, and no strictly conforming program can
use identifiers starting with __ except where they are explicitly
defined by the standard.

Well, strictly conforming programs are not interesting:
they are fine and there is nothing to worry about. It's
non-strictly-conforming programs which we want the compiler
to tell us about, like those containing // comments.
It's an interesting point that an implementation can get
away with anything as long as it *could* be that it behaved
in certain way :)

Yevgen

[ymuntyan]

On Apr 27, 5:20 am, Keith Thompson <[e-mail]:

Ian Collins <[e-mail]:

[e-mail] wrote:

On Apr 26, 8:31 pm, Chris Torek <[e-mail]:

>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". :-)

I believe I understand what you're saying, yet I don't
quite understand where that fine line between "syntax
error" and "not a syntax error" is drawn. Namely, why
is // a deviation from the C syntax which must be diagnosed,
while __attribute__ isn't? Or why __attribute__ is fine
while 234i literal isn't?

__attribute__ is in the implementation's namespace, so the
implementation is free to treat it how is sees fit. 234i is not.

Yes, but ...

__attribute__ is an identifier, a valid token, so by itself it's not
necessarily a syntax error. 234i is not a valid token.

So, the question is: where exactly does the standard say
that implementation is free to use any __-prefixed identifier
as a magic word which may completely change semantics of the
program? It does say that such identifiers are reserved,
yet they still are identifiers.

Reserved, for the implementation. So it can do what it likes with them.

Within limits.

I'll quote from the C99 standard, because my copy of it is easier to
copy-and-paste from than my copy of the C90 standard. C90 has similar
rules.

C99 4p6:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.

with a footnote:

This implies that a conforming implementation reserves no
identifiers other than those explicitly reserved in this
International Standard.

For example, since the identifier __attribute__ is reserved to the
implementation, no strictly conforming program may use it; therefore,
a conforming implementation may provide an extension that affects only
programs that use the identifier __attribute__.

A program which uses // comments isn't strictly conforming
either, so a conforming implementation may provide an extension...

>
But must the implementation still issue a diagnostic if the use of an
extension violates a constraint or syntax rule? In my opinion, the
answer is yes; the standard permits extensions, but that doesn't
override the requirement to issue a diagnostic. Doug Gwyn, a member
of the C standard committee, has expressed the same opinion over on
comp.std.c.

Sounds right, and it doesn't explain why __attribute__ may get
away without a warning :)

[snip]

Yevgen

[Ben Bacarisse]

jacob navia <ja***@nospam.comwrites:

Ben Bacarisse wrote:

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

All the bugs you mentioned were fixed as quickly as I could.

That is good, but if the fixes don't show up in the compiler and you
don't reply to the postings about them, how can anyone tell? Do you
post a list of fixes and when they will get into the released
compiler?

I one case (of VLA array parameters) you did not reply to the posting
about it (I may have missed it of course) so I was not even sure you
confirmed it as a bug. It is certainly still there in the compiler as
are a lot of the others (I have more if you really want them).

That is not, of course, TOP PRIORITY. Some bugs were
fixed in less than a few hours. But that is NOT TOP PRIORITY.

What, then, would be TOP PRIORITY?

Top priority would be to finish C99 features before adding
extensions. I know one of the extensions is your intended way to
implement one part of C99 (complex numbers) but that is not true of
the others, is it?

I am not criticising this decision. It makes perfect commercial
sense to include extensions your customers rely on, but if standards
compliance were your top priority, it would be done first, almost by
definition.

--
Ben.

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <rj*@see.sig.invalidwrites:
[...]

>So: to clarify, the appearance of a // in a C90 program is either:

(a) part of a string literal " like // this "; or
(b) part of a comment /* like // this */; or
(c) a division followed immediately by a comment like//*this*/that; or
(d) a syntax error.

I think that covers all the possibilities.

Not quite.

<grinI am *so* glad I said "I think...". Weasel words are a very present
help in time of trouble!

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bartc]

"Keith Thompson" <ks***@mib.orgwrote in message
news:87************@kvetch.smov.org...

Keith Thompson <ks***@mib.orgwrites:

>Richard Heathfield <rj*@see.sig.invalidwrites:
[...]

>>So: to clarify, the appearance of a // in a C90 program is either:

(a) part of a string literal " like // this "; or
(b) part of a comment /* like // this */; or
(c) a division followed immediately by a comment like//*this*/that; or
(d) a syntax error.

I think that covers all the possibilities.

Not quite.

(e) part of a multi-character character constant, such as '//' or
L'//'; or
(f) part of a header name, such as #include <foo//bar.hor
#include "foo//bar.h" (no, the latter is not actually a string
literal)
(g) part of a sequence of preprocessor tokens that are discarded, as in:
#define IGNORE(x) /* nothing */
IGNORE(//)
or
#if 0
// no, this isn't a comment
#endif
; or
(h) part of a #error directive (though this causes the translation
unit to be rejected); or
(i) part of an implementation-defined #pragma directive.

I *think* that covers all the cases, but I wouldn't swear to it.

[...]

(j) a comment followed immediately by a division like/*this*//that
(the reverse of case (c)).

Why would this be a problem? It's clearly a /*...*/ comment followed by
division; no ambiguity. Otherwise you can have other cases such as /*
comment 1 *//* comment 2 */

--
Bartc

[CBFalconer]

Keith Thompson wrote:

>

.... snip ...

>
I'll quote from the C99 standard, because my copy of it is easier
to copy-and-paste from than my copy of the C90 standard. C90 has
similar rules.

N869.txt is ideal for the purpose, and easily available as:

<http://cbfalconer.home.att.net/download/n869_txt.bz2>

which is only about 210 kB bzip2 compressed.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Keith Thompson]

"Bartc" <[e-mail]:

"Keith Thompson" <ks***@mib.orgwrote in message
news:87************@kvetch.smov.org...

>Keith Thompson <ks***@mib.orgwrites:

[...]

>>I *think* that covers all the cases, but I wouldn't swear to it.

[...]

(j) a comment followed immediately by a division like/*this*//that
(the reverse of case (c)).

Why would this be a problem? It's clearly a /*...*/ comment followed by
division; no ambiguity. Otherwise you can have other cases such as /*
comment 1 *//* comment 2 */

It's not a problem, and I didn't say it was. "//" in a string literal
isn't a problem wither. We were enumerating the circumstances in
which // can appear in a C90 program.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Keith Thompson wrote:

>>

... snip ...

>>
I'll quote from the C99 standard, because my copy of it is easier
to copy-and-paste from than my copy of the C90 standard. C90 has
similar rules.

N869.txt is ideal for the purpose, and easily available as:

<http://cbfalconer.home.att.net/download/n869_txt.bz2>

which is only about 210 kB bzip2 compressed.

No, it's very bad for the purpose. N869.txt is a draft of the C99
standard. The problem I was having was that I don't have a copy of
the C90 standard from which I can easily copy-and-paste. (I already
have a PDF copy of the C99 standard; I can copy-and-paste from it with
no problem.)

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

ym******@gmail.com writes:

On Apr 27, 5:20 am, Keith Thompson <[e-mail]:

[...]

>For example, since the identifier __attribute__ is reserved to the
implementation, no strictly conforming program may use it; therefore,
a conforming implementation may provide an extension that affects only
programs that use the identifier __attribute__.

A program which uses // comments isn't strictly conforming
either, so a conforming implementation may provide an extension...

Exactly. *But* that doesn't relieve the implementation of its
obligation to diagnose syntax errors.

>But must the implementation still issue a diagnostic if the use of an
extension violates a constraint or syntax rule? In my opinion, the
answer is yes; the standard permits extensions, but that doesn't
override the requirement to issue a diagnostic. Doug Gwyn, a member
of the C standard committee, has expressed the same opinion over on
comp.std.c.

Sounds right, and it doesn't explain why __attribute__ may get
away without a warning :)

The C standard conformance police haven't caught up with them yet,
probably because they don't exist.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Hans Schneider]

teapot schrieb:

>
If I compile this program

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

That is no useful comment.

According to article <ds**********@yin.interaccess.com>,
"foo" and "bar" are not standardisiert.

>
with

"lc -A -ansi89 foo.c"

Where is -ansi89 described?

I have lcc-win32 version 3.8 and it says only what -ansic is
but not -ansi89.

Why can you know it exists?

I think -ansi89 is not official.

>
(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)?

[Peter Nilsson]

Richard Heathfield wrote:

... the appearance of a // in a C90 program is either:

(a) part of a string literal " like // this "; or

(aa) character constant like '//'; or
(ab) token sequence to be stringised, like...

#define STR(x) #x
puts(STR(//));

; or

(b) part of a comment /* like // this */; or
(c) a division followed immediately by a comment like//*this*/that; or

(e) ignored conditional block like...

#if 0
What do you mean // is not valid?
#endif

; or

(d) a syntax error.

I think that covers all the possibilities.

It can appear in a #include directive...

#include <//samba/usr/include/header.h>

.... though that probably excludes it from being a 'C90' program.
What's your view on it appearing in a #error directive?

--
Peter

[Peter Nilsson]

Oops, I didn't mean to send previous reply after reading Keith's.

Peter Nilsson wrote:

Richard Heathfield wrote:

... the appearance of a // in a C90 program is either:

(a) part of a string literal " like // this "; or

(aa) character constant like '//'; or

<snip>

--
Peter