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

// comments

P: n/a
Recently we had poor Mr "teapot" that was horrified at the heresy
of lcc-win of accepting // comments.

C is a nice language, and you can do anything with it, inclusive a
program that transforms // comments into well behaved /* ... */
ones...

------------------------------------------------cut here

/*
This program reads a C source file and writes it modified to stdout
All // comments will be replaced by / * ... * / comments, to easy the
porting to old environments or to post it in usenet, where
// comments can be broken in several lines, and messed up.
*/

#include <stdio.h>
#include <stdlib.h>

/* This function reads a character and writes it to stdout */
static int Fgetc(FILE *f)
{
int c = fgetc(f);
if (c != EOF)
putchar(c);
return c;

}

/* This function skips strings */
static int ParseString(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;
}

/* Skips multi-line comments */
static int ParseComment(FILE *f)
{
int c = Fgetc(f);

while (1) {
while (c != '*') {
c = Fgetc(f);
if (c == EOF)
return EOF;
}
c = Fgetc(f);
if (c == '/')
break;
}
return Fgetc(f);

}

/* Skips // comments. Note that we use fgetc here and NOT Fgetc */
/* since we want to modify the output before gets echoed */
static int ParseCppComment(FILE *f)
{
int c = fgetc(f);

while (c != EOF && c != '\n') {
putchar(c);
c = fgetc(f);
if (c == '*') {
c = fgetc(f);
if (c == '/') {
c = fgetc(f);
putchar(' ');
}
else {
putchar('*');
}
}
}
if (c == '\n') {
puts(" */");
c = Fgetc(f);
}
return c;

}

/* Checks if a comment is followed after a '/' char */
static int CheckComment(int c,FILE *f)
{
if (c == '/') {
c = fgetc(f);
if (c == '*') {
putchar('*');
c = ParseComment(f);
}
else if (c == '/') {
putchar('*');
c = ParseCppComment(f);
}
else {
putchar(c);
c = Fgetc(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[])
{
FILE *f;
int c;
if (argc == 1) {
puts("Usage: give an input file name. Writes to stdout");
return EXIT_FAILURE;
}
f = fopen(argv[1],"r");
if (f == NULL) {
puts("Can't find the input file");
return EXIT_FAILURE;
}
c = Fgetc(f);
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 = CheckComment(c,f);
break;
case '\'':
c = ParseQuotedChar(f);
break;
default:
c = Fgetc(f);
}
}
fclose(f);
return 0;

}

----------------------------------------------------------cut here

Note that trigraphs are not supported. Homework: Add that feature

Compiled with lcc-win, this program makes only 3 616 bytes. C is
an efficient language.

P.S. Note that I have avoided printf... If you add printf the size
will be a HUGE 37K.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jun 27 '08 #1
Share this Question
Share on Google+
40 Replies


P: n/a
jacob navia <ja***@nospam.comwrites:
Recently we had poor Mr "teapot" that was horrified at the heresy
of lcc-win of accepting // comments.
Can you clear up the question of what the -ansi89 flag is intended to
do? Your compiler is allowed to accept any extensions it likes and to
reject and conforming C90 programs it wishes to *unless* you claim that
lc -ansi89 is intended to be a conforming C90 implementation. What is
the purpose of -ansi89?
C is a nice language, and you can do anything with it, inclusive a
program that transforms // comments into well behaved /* ... */
ones...
How do you do that with:

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

Is this a valid C90 program or an incorrect C90 one that has a //
comment int it?

<snip program>
Note that trigraphs are not supported. Homework: Add that feature
I also does not treat multi-line // comments correctly.

--
Ben.
Jun 27 '08 #2

P: n/a
jacob navia said:
Recently we had poor Mr "teapot" that was horrified at the heresy
of lcc-win of accepting // comments.
It is surely not too surprising that at least one user is horrified by the
idea that a supposedly conforming C90 implementation fails to produce a
diagnostic message for a syntax error. We knew lcc-win32 didn't conform to
C99. Now it appears it doesn't appear to conform to C90 either.

Does it at least have a K&R C mode? If not, it would seem that it isn't
actually a C compiler after all, and is therefore off-topic in
comp.lang.c.
C is a nice language, and you can do anything with it, inclusive a
program that transforms // comments into well behaved /* ... */
ones...
....and fails not only on trigraphs (as you pointed out) but also on the
following input:

/\
/ double-slash comment with line-splice

--
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
Jun 27 '08 #3

P: n/a
Ben Bacarisse wrote:
jacob navia <ja***@nospam.comwrites:
>Recently we had poor Mr "teapot" that was horrified at the heresy
of lcc-win of accepting // comments.

Can you clear up the question of what the -ansi89 flag is intended to
do? Your compiler is allowed to accept any extensions it likes and to
reject and conforming C90 programs it wishes to *unless* you claim that
lc -ansi89 is intended to be a conforming C90 implementation. What is
the purpose of -ansi89?
-ansi89 was implemented to the wishes of a paying customer. They wanted
a compiler to that standard, and I implemented it for them. The usage of
that flag is to disable most C99 stuff.

Note that many compilers at the C89 level accept // comments, for instance
Microsoft compilers

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jun 27 '08 #4

P: n/a
jacob navia <ja***@nospam.comwrites:
Ben Bacarisse wrote:
>jacob navia <ja***@nospam.comwrites:
>>Recently we had poor Mr "teapot" that was horrified at the heresy
of lcc-win of accepting // comments.

Can you clear up the question of what the -ansi89 flag is intended to
do? Your compiler is allowed to accept any extensions it likes and to
reject and conforming C90 programs it wishes to *unless* you claim that
lc -ansi89 is intended to be a conforming C90 implementation. What is
the purpose of -ansi89?

-ansi89 was implemented to the wishes of a paying customer. They wanted
a compiler to that standard, and I implemented it for them. The usage of
that flag is to disable most C99 stuff.
If your paying customer is satisfied with that, then that's fine.
However, the ANSI C89 standard (or equivalently the ISO C90 standard)
requires a diagnostic for a "//" comment (except in the rare cases
where it can be a legal C89 construct, such as a division operator
immediately followed by a comment). If your compiler doesn't issue a
diagnostic for a "//" comment, then it's not a 100% conforming C89
compiler. I hope that your documentation makes that clear.

Since it's easy enough to implement full C89 conformance in this area
by issuing a warning, perhaps just on the first occurrence in a
translation unit, I fail to understand why you wouldn't go ahead and
do so, but that's up to you.
Note that many compilers at the C89 level accept // comments, for instance
Microsoft compilers
Then my comment applies to them as well.

(If you perceive a personal attack in the above, or an attack on
lcc-win, or on C99, or on // comments, then you've misunderstood me.
Again.)

--
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"
Jun 27 '08 #5

P: n/a
Keith Thompson said:
jacob navia <ja***@nospam.comwrites:
<snip>
>Note that many compilers at the C89 level accept // comments,
If they are invoked in conforming mode, they *must* diagnose syntax errors.
>for instance Microsoft compilers

Then my comment applies to them as well.
When invoked in conforming mode, Microsoft C (or at least my copy of it)
issues the necessary diagnostic message if you use // in an erroneous
syntactical context.

<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
Jun 27 '08 #6

P: n/a
Richard Heathfield wrote:
Keith Thompson said:
>jacob navia <ja***@nospam.comwrites:

<snip>
>>Note that many compilers at the C89 level accept // comments,

If they are invoked in conforming mode, they *must* diagnose syntax errors.
Maybe. If they do not, please use another compiler.
>>for instance Microsoft compilers
Then my comment applies to them as well.

When invoked in conforming mode, Microsoft C (or at least my copy of it)
issues the necessary diagnostic message if you use // in an erroneous
syntactical context.

D:\lcc\mc71\test>type tt.c
// aaaaa

D:\lcc\mc71\test>cl -W4 tt.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

tt.c
tt.c(2) : warning C4206: nonstandard extension used : translation unit
is empty

Of course your version dates from 1991... Always the same word games,
half truths, etc. Pure regulars BS.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jun 27 '08 #7

P: n/a
On Apr 27, 1:27 am, jacob navia <ja...@nospam.comwrote:
Recently we had poor Mr "teapot" that was horrified at the heresy
of lcc-win of accepting // comments.
You seem horrified too. Or horrifying.
C is a nice language, and you can do anything with it, inclusive a
program that transforms // comments into well behaved /* ... */
ones...
Actually, you cannot, at least not correctly. It's impossible to guess
the intend of the programmer in:
int main(void) { return 1//* divide? */2; }
As noted by Mr Bacarisse (but I have seen that example in other places
too)
<snip code>
>
Note that trigraphs are not supported. Homework: Add that feature
Nor digraphs.
Compiled with lcc-win, this program makes only 3 616 bytes. C is
an efficient language.
I think what you're trying to say here is that lcc-win is efficient,
and not C. A language cannot be efficient, not in that sense.
P.S. Note that I have avoided printf... If you add printf the size
will be a HUGE 37K.
Maybe your compiler is not that efficient then (or maybe you did not
mention how you linked the lib).
Here with gcc I get 8K with no optimizations (using or not using
printf).
I wouldn't expect from someone who complains about "the regulars"
mentioning old systems to prove him wrong, to actually mention 37K as
a "HUGE" size. 37K is _nothing_ in a modern computer.
Jun 27 '08 #8

P: n/a
jacob navia wrote, On 27/04/08 08:59:
Richard Heathfield wrote:
>Keith Thompson said:
>>jacob navia <ja***@nospam.comwrites:

<snip>
>>>Note that many compilers at the C89 level accept // comments,

If they are invoked in conforming mode, they *must* diagnose syntax
errors.

Maybe. If they do not, please use another compiler.
If you state that -ansi89 does *not* mean conformance to C89 (or C90 or
C95) then as has already been stated it is allowed to accept whatever
you want. If I was one of your paying customers I would not be happy,
but I'm not.
>>>for instance Microsoft compilers
Then my comment applies to them as well.

When invoked in conforming mode, Microsoft C (or at least my copy of
it) issues the necessary diagnostic message if you use // in an
erroneous syntactical context.

D:\lcc\mc71\test>type tt.c
// aaaaa

D:\lcc\mc71\test>cl -W4 tt.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

tt.c
tt.c(2) : warning C4206: nonstandard extension used : translation unit
is empty

Of course your version dates from 1991... Always the same word games,
half truths, etc. Pure regulars BS.
Not at all. You have just demonstrated that what Richard said is true
for the version you have as well. The compiler emitted a diagnostic.
There is no requirement for it to produce an error or abort the
translation. I have already posted saying that all you have to do is
detect it and issue a warning, as has Keith.
--
Flash Gordon
Jun 27 '08 #9

P: n/a
Flash Gordon wrote:
jacob navia wrote, On 27/04/08 08:59:
>Richard Heathfield wrote:
>>When invoked in conforming mode, Microsoft C (or at least my copy of
it) issues the necessary diagnostic message if you use // in an
erroneous syntactical context.

D:\lcc\mc71\test>type tt.c
// aaaaa

D:\lcc\mc71\test>cl -W4 tt.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

tt.c
tt.c(2) : warning C4206: nonstandard extension used : translation unit
is empty

Of course your version dates from 1991... Always the same word games,
half truths, etc. Pure regulars BS.

Not at all. You have just demonstrated that what Richard said is true
for the version you have as well. The compiler emitted a diagnostic.
There is no requirement for it to produce an error or abort the
translation. I have already posted saying that all you have to do is
detect it and issue a warning, as has Keith.
word games, word games
// aaaaaaa
int a=0;

Now, cl doesn't give any warning:
D:\lcc\mc71\test>cl -W4 -c tt.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x6
Copyright (C) Microsoft Corporation. All rights reserved.

tt.c

D:\lcc\mc71\test>

WORD GAMES as always.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jun 27 '08 #10

P: n/a
jacob navia wrote:
Flash Gordon wrote:
>jacob navia wrote, On 27/04/08 08:59:
>>Richard Heathfield wrote:
When invoked in conforming mode, Microsoft C (or at least my copy
of it) issues the necessary diagnostic message if you use // in an
erroneous syntactical context.

D:\lcc\mc71\test>type tt.c
// aaaaa

D:\lcc\mc71\test>cl -W4 tt.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for
x64
Copyright (C) Microsoft Corporation. All rights reserved.

tt.c
tt.c(2) : warning C4206: nonstandard extension used : translation
unit is empty

Of course your version dates from 1991... Always the same word
games, half truths, etc. Pure regulars BS.

Not at all. You have just demonstrated that what Richard said is true
for the version you have as well. The compiler emitted a diagnostic.
There is no requirement for it to produce an error or abort the
translation. I have already posted saying that all you have to do is
detect it and issue a warning, as has Keith.

word games, word games
// aaaaaaa
int a=0;

Now, cl doesn't give any warning:
D:\lcc\mc71\test>cl -W4 -c tt.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x6
Copyright (C) Microsoft Corporation. All rights reserved.

tt.c

D:\lcc\mc71\test>

WORD GAMES as always.
Well, what do you expect if you do not tell CL to disable language
extensions? Add the /Za switch and also the /Wall switch and try again.

Jun 27 '08 #11

P: n/a
jacob navia <ja***@nospam.comwrites:
Flash Gordon wrote:
>jacob navia wrote, On 27/04/08 08:59:
>>Richard Heathfield wrote:
When invoked in conforming mode, Microsoft C (or at least my copy
of it) issues the necessary diagnostic message if you use // in an
erroneous syntactical context.

D:\lcc\mc71\test>type tt.c
// aaaaa

D:\lcc\mc71\test>cl -W4 tt.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

tt.c
tt.c(2) : warning C4206: nonstandard extension used : translation
unit is empty

Of course your version dates from 1991... Always the same word games,
half truths, etc. Pure regulars BS.

Not at all. You have just demonstrated that what Richard said is
true for the version you have as well. The compiler emitted a
diagnostic. There is no requirement for it to produce an error or
abort the translation. I have already posted saying that all you
have to do is detect it and issue a warning, as has Keith.

word games, word games
// aaaaaaa
int a=0;

Now, cl doesn't give any warning:
D:\lcc\mc71\test>cl -W4 -c tt.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x6
Copyright (C) Microsoft Corporation. All rights reserved.

tt.c

D:\lcc\mc71\test>

WORD GAMES as always.
I don't think the phrase "word games" means what you think it means.

You have demonstrated that Microsoft's C compiler, invoked with the
options you specified, is not a conforming C89/C90 compiler. If it
were, it would have issued a diagnostic for the "//".

I don't know whether "cl -W4 -c tt.c" invokes it in what is intended
to be C90 conforming mode. If not, you haven't demonstrated anything
of any significance.

*At most*, you've simply demonstrated that, *if* lcc-win's "-ansi89"
option is intended to invoke it in C89 conforming mode, then it
exhibits a bug (a failure to conform to the C89 standard) that
Microsoft's compiler also exhibits.

None of this matters much to me personally. Since it appears to
matter a great deal to you, perhaps you can answer these questions and
clear this up:

1. Is lcc-win's "-ansi89" option intended to invoke the compiler in a
mode that conforms to the ANSI C89 standard?

2. In that mode, does it issue a diagnostic for a "//" comment?

3. If it doesn't, do you acknowledge that that is a conformance
failure?

If this is a bug, I'm not saying it's terrifying, and I'm not pushing
to you fix it. I'm only asking you to clear up this issue.

--
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"
Jun 27 '08 #12

P: n/a
On Apr 27, 4:26 am, Flash Gordon <s...@flash-gordon.me.ukwrote:
jacob navia wrote, On 27/04/08 08:59:
Richard Heathfield wrote:
Keith Thompson said:
>jacob navia <ja...@nospam.comwrites:
<snip>
>>Note that many compilers at the C89 level accept // comments,
If they are invoked in conforming mode, they *must* diagnose syntax
errors.
Maybe. If they do not, please use another compiler.

If you state that -ansi89 does *not* mean conformance to C89 (or C90 or
C95) then as has already been stated it is allowed to accept whatever
you want. If I was one of your paying customers I would not be happy,
but I'm not.
Perhaps that customer wanted warnings for stuff which
reduces portability, like variadic macros not understood
by MS compiler?
(Yes I do realize that where were, and hence are, C compilers
which do not understand // comments)

Yevgen
Jun 27 '08 #13

P: n/a
On Apr 27, 6:02 am, ymunt...@gmail.com wrote:
On Apr 27, 4:26 am, Flash Gordon <s...@flash-gordon.me.ukwrote:
jacob navia wrote, On 27/04/08 08:59:
Richard Heathfield wrote:
>Keith Thompson said:
>>jacob navia <ja...@nospam.comwrites:
><snip>
>>>Note that many compilers at the C89 level accept // comments,
>If they are invoked in conforming mode, they *must* diagnose syntax
>errors.
Maybe. If they do not, please use another compiler.
If you state that -ansi89 does *not* mean conformance to C89 (or C90 or
C95) then as has already been stated it is allowed to accept whatever
you want. If I was one of your paying customers I would not be happy,
but I'm not.

Perhaps that customer wanted warnings for stuff which
reduces portability, like variadic macros not understood
by MS compiler?
(Yes I do realize that where were, and hence are, C compilers
which do not understand // comments)
Actually I was wrong, I have no idea if there was a C
compiler which didn't understand // comments. By the time
when a compiler got to C90 conformance (N years after 1990),
// comments were probably already there. What conforming C90
compiler doesn't understand // comments? Just curious.

Yevgen
Jun 27 '08 #14

P: n/a
ym******@gmail.com writes:
On Apr 27, 4:26 am, Flash Gordon <s...@flash-gordon.me.ukwrote:
>jacob navia wrote, On 27/04/08 08:59:
<snip>
>If you state that -ansi89 does *not* mean conformance to C89 (or C90 or
C95) then as has already been stated it is allowed to accept whatever
you want. If I was one of your paying customers I would not be happy,
but I'm not.

Perhaps that customer wanted warnings for stuff which
reduces portability, like variadic macros not understood
by MS compiler?
Then they would be disappointed. I am not sure to what extent it is
either wise or topical to go into details but -ansi89 does not
diagnose variadic macros (as it should). Fortunately, the
implementation of them seems to be broken so the user would likely
find out if they tried to use them. It seems that -ansi89 also
permits long long int, treats restrict as a keyword, does not diagnose
the use of compound literals, permits [static N] in function
parameters... I stopped looking after a while[1].

Its use for checking portability would be rather limited, I think.

[1] To be balanced, it does diagnose some non ANSI C constructs.

--
Ben.
Jun 27 '08 #15

P: n/a
jacob navia wrote, On 27/04/08 11:05:
Flash Gordon wrote:
>jacob navia wrote, On 27/04/08 08:59:
>>Richard Heathfield wrote:
When invoked in conforming mode, Microsoft C (or at least my copy of
it) issues the necessary diagnostic message if you use // in an
erroneous syntactical context.

D:\lcc\mc71\test>type tt.c
// aaaaa

D:\lcc\mc71\test>cl -W4 tt.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

tt.c
tt.c(2) : warning C4206: nonstandard extension used : translation
unit is empty

Of course your version dates from 1991... Always the same word games,
half truths, etc. Pure regulars BS.

Not at all. You have just demonstrated that what Richard said is true
for the version you have as well. The compiler emitted a diagnostic.
There is no requirement for it to produce an error or abort the
translation. I have already posted saying that all you have to do is
detect it and issue a warning, as has Keith.

word games, word games
No, statements of fact.
// aaaaaaa
int a=0;

Now, cl doesn't give any warning:
D:\lcc\mc71\test>cl -W4 -c tt.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x6
Copyright (C) Microsoft Corporation. All rights reserved.

tt.c

D:\lcc\mc71\test>

WORD GAMES as always.
You are the one playing word games. You know very well that if MS VC++
is invoked in conforming more it *does* produce a diagnostic for //
style comments. That is does not when *not* in conforming mode is *not*
an excuse for your compiler to fail to produce required diagnostics in a
claimed C89 conforming mode.

Also MS VCC++ not producing a diagnostic in non-conforming mode does not
contradict what Richard says above.

Either accept that on your compiler -ansi89 does not make it conforming
(which would seem strange to me but it's your choice) or accept that you
have a bug. Do not try and use the non-conforming mode of other
compilers as an excuse if you are attempting to provide a conforming mode.
--
Flash Gordon
Jun 27 '08 #16

P: n/a
Ben Bacarisse wrote:
ym******@gmail.com writes:
>On Apr 27, 4:26 am, Flash Gordon <s...@flash-gordon.me.ukwrote:
>>jacob navia wrote, On 27/04/08 08:59:
<snip>
>>If you state that -ansi89 does *not* mean conformance to C89 (or C90
or C95) then as has already been stated it is allowed to accept
whatever you want. If I was one of your paying customers I would not
be happy, but I'm not.

Perhaps that customer wanted warnings for stuff which
reduces portability, like variadic macros not understood
by MS compiler?

Then they would be disappointed. I am not sure to what extent it is
either wise or topical to go into details but -ansi89 does not
diagnose variadic macros (as it should). Fortunately, the
implementation of them seems to be broken so the user would likely
find out if they tried to use them. It seems that -ansi89 also
permits long long int, treats restrict as a keyword, does not diagnose
the use of compound literals, permits [static N] in function
parameters... I stopped looking after a while[1].

Its use for checking portability would be rather limited, I think.

[1] To be balanced, it does diagnose some non ANSI C constructs.
Maybe jacob implemented -ansi89 switch as a synonym for -ansi?

Jun 27 '08 #17

P: n/a
jacob navia said:
Richard Heathfield wrote:
<snip>
>When invoked in conforming mode, Microsoft C (or at least my copy of it)
issues the necessary diagnostic message if you use // in an erroneous
syntactical context.


D:\lcc\mc71\test>type tt.c
// aaaaa

D:\lcc\mc71\test>cl -W4 tt.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

tt.c
tt.c(2) : warning C4206: nonstandard extension used : translation unit
is empty

Of course your version dates from 1991... Always the same word games,
half truths, etc. Pure regulars BS.
Firstly, even a conforming implementation is only obliged to issue *one*
diagnostic message for any translation unit that violates any syntactic
rules or constraints, and the form of that message is up to the
implementation. If a translation unit contains two or more such
violations, an implementation only need diagnose one of them. In that
respect, your log does not prove that MS C violates conformance by not
producing the diagnostic message you'd like to see - by producing one at
all, it conforms.

Secondly, you have not even invoked it in conforming mode!

It seems that you are determined to fail to understand the point being made
here. Now try adding the -Za switch to your invocation, to instruct MS C
to disable language extensions. Then give it a translation unit that
contains no other violations of syntactic rules or constraints - for
example:

#include <stdio.h>

int main(void)
{
puts("Hello, world!"); // this is a syntax error
return 0;
}

If you call this translation unit tt.c and invoke Microsoft C in conforming
mode as follows:

cl -W4 -Za tt.c

what diagnostic messages do you get?

--
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
Jun 27 '08 #18

P: n/a
santosh <sa*********@gmail.comwrites:
Ben Bacarisse wrote:
>ym******@gmail.com writes:
<snip>
>>Perhaps that customer wanted warnings for stuff which
reduces portability, like variadic macros not understood
by MS compiler?

Then they would be disappointed.
<snip>
>[1] To be balanced, it does diagnose some non ANSI C constructs.

Maybe jacob implemented -ansi89 switch as a synonym for -ansi?
Sorry, I don't follow.

--
Ben.
Jun 27 '08 #19

P: n/a
On Sun, 27 Apr 2008 13:36:20 +0100, Ben Bacarisse wrote:
santosh <sa*********@gmail.comwrites:
>Maybe jacob implemented -ansi89 switch as a synonym for -ansi?

Sorry, I don't follow.
With GCC, -ansi means that valid C90 programs will be accepted, but
invalid C90 programs, complete with syntax errors and/or constraint
violations, will not necessarily be rejected. It's possible that jacob
navia made -ansi89 behave the same way in lcc-win32.
Jun 27 '08 #20

P: n/a

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...
jacob navia <ja***@nospam.comwrites:
>Recently we had poor Mr "teapot" that was horrified at the heresy
of lcc-win of accepting // comments.

Can you clear up the question of what the -ansi89 flag is intended to
do? Your compiler is allowed to accept any extensions it likes and to
reject and conforming C90 programs it wishes to *unless* you claim that
lc -ansi89 is intended to be a conforming C90 implementation. What is
the purpose of -ansi89?
>C is a nice language, and you can do anything with it, inclusive a
program that transforms // comments into well behaved /* ... */
ones...

How do you do that with:

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

Is this a valid C90 program or an incorrect C90 one that has a //
comment int it?
I think it's more of a problem of the design of the // comment convention,
in that this ambiguity can occur.

I would guess that in the case of Jacob's code, it's assuming input is of a
file where // can legally occur. It will translate that into a form that
will give a compilation error (in any mode). Then the user can trace back
and see immediately where the problem is.

That's no different from feeding this code to practically any compiler that
by default accepts // comments; it will report an error and the user can
either invoke conforming mode or (more sensibly so that it gives no further
problems) turn // into / /).

For Jacob's code to work sensibly, it would need a switch to tell it the
input has pure C90-conforming comments, but if someone knew that, there
would be no need to run the program!

--
Bartc
Jun 27 '08 #21

P: n/a
Harald van Dijk <tr*****@gmail.comwrites:
On Sun, 27 Apr 2008 13:36:20 +0100, Ben Bacarisse wrote:
>santosh <sa*********@gmail.comwrites:
>>Maybe jacob implemented -ansi89 switch as a synonym for -ansi?

Sorry, I don't follow.

With GCC, -ansi means that valid C90 programs will be accepted, but
invalid C90 programs, complete with syntax errors and/or constraint
violations, will not necessarily be rejected. It's possible that jacob
navia made -ansi89 behave the same way in lcc-win32.
I considered that meaning, but since santosh was replying to a message
that stated that -ansi89 treats restrict as a keyword, that did not
seem like a reasonable interpretation.

--
Ben.
Jun 27 '08 #22

P: n/a
Ben Bacarisse wrote:
Harald van D?k <tr*****@gmail.comwrites:
>On Sun, 27 Apr 2008 13:36:20 +0100, Ben Bacarisse wrote:
>>santosh <sa*********@gmail.comwrites:
Maybe jacob implemented -ansi89 switch as a synonym for -ansi?

Sorry, I don't follow.

With GCC, -ansi means that valid C90 programs will be accepted, but
invalid C90 programs, complete with syntax errors and/or constraint
violations, will not necessarily be rejected. It's possible that
jacob navia made -ansi89 behave the same way in lcc-win32.

I considered that meaning, but since santosh was replying to a message
that stated that -ansi89 treats restrict as a keyword, that did not
seem like a reasonable interpretation.
Yes. The lcc-win manual that I have indicates that the -ansi switch
makes the compiler conform to C99. Your post up-thread which seemed to
indicate that lcc-win accepted several C99 constructs when
under -ansi89 suggested to me that jacob might have simply made -ansi89
a synonym for -ansi with a few more check (presumably whatever his
paying customer asked for) added in. This would mean that -ansi89 isn't
really suitable for making lcc-win conform to C90. This is also borne
out by the fact that the -ansi89 switch isn't listed in the lcc-win
manual I have here.

Jun 27 '08 #23

P: n/a
On Sun, 27 Apr 2008 18:52:20 +0530, santosh wrote:
Ben Bacarisse wrote:
>Harald van D?k <tr*****@gmail.comwrites:
>>On Sun, 27 Apr 2008 13:36:20 +0100, Ben Bacarisse wrote:
santosh <sa*********@gmail.comwrites:
Maybe jacob implemented -ansi89 switch as a synonym for -ansi?

Sorry, I don't follow.

With GCC, -ansi means that valid C90 programs will be accepted, but
invalid C90 programs, complete with syntax errors and/or constraint
violations, will not necessarily be rejected. It's possible that jacob
navia made -ansi89 behave the same way in lcc-win32.

I considered that meaning, but since santosh was replying to a message
that stated that -ansi89 treats restrict as a keyword, that did not
seem like a reasonable interpretation.

Yes. The lcc-win manual that I have indicates that the -ansi switch
makes the compiler conform to C99. [...]
Interesting. I still happened to have the Linux version of lcc installed,
and it doesn't support any -ansi option, but does support the -ansi89
option.

Warning 0 Ignoring unknown option '-ansi'

Because of that, I didn't consider the possibility of an lcc option -ansi
since added.
Jun 27 '08 #24

P: n/a
Harald van D?k wrote:
On Sun, 27 Apr 2008 18:52:20 +0530, santosh wrote:
>Ben Bacarisse wrote:
>>Harald van D?k <tr*****@gmail.comwrites:
On Sun, 27 Apr 2008 13:36:20 +0100, Ben Bacarisse wrote:
santosh <sa*********@gmail.comwrites:
>Maybe jacob implemented -ansi89 switch as a synonym for -ansi?
>
Sorry, I don't follow.

With GCC, -ansi means that valid C90 programs will be accepted, but
invalid C90 programs, complete with syntax errors and/or constraint
violations, will not necessarily be rejected. It's possible that
jacob navia made -ansi89 behave the same way in lcc-win32.

I considered that meaning, but since santosh was replying to a
message that stated that -ansi89 treats restrict as a keyword, that
did not seem like a reasonable interpretation.

Yes. The lcc-win manual that I have indicates that the -ansi switch
makes the compiler conform to C99. [...]

Interesting. I still happened to have the Linux version of lcc
installed, and it doesn't support any -ansi option, but does support
the -ansi89 option.

Warning 0 Ignoring unknown option '-ansi'

Because of that, I didn't consider the possibility of an lcc option
-ansi since added.
I too still have the aborted Linux version installed, but the
information above was taken from the installation lcc-win32 under WINE.

Jun 27 '08 #25

P: n/a
"Bartc" <bc@freeuk.comwrites:
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...
>jacob navia <ja***@nospam.comwrites:
>>Recently we had poor Mr "teapot" that was horrified at the heresy
of lcc-win of accepting // comments.

Can you clear up the question of what the -ansi89 flag is intended to
do? Your compiler is allowed to accept any extensions it likes and to
reject and conforming C90 programs it wishes to *unless* you claim that
lc -ansi89 is intended to be a conforming C90 implementation. What is
the purpose of -ansi89?
>>C is a nice language, and you can do anything with it, inclusive a
program that transforms // comments into well behaved /* ... */
ones...

How do you do that with:

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

Is this a valid C90 program or an incorrect C90 one that has a //
comment int it?

I think it's more of a problem of the design of the // comment convention,
in that this ambiguity can occur.
That is true. The supposition made by the utility is that the above
program needs fixing. The problem I cite is really only a problem for
a "C90 compiler with // comments". Such a compiler needs to choose
between the interpretations.

--
Ben.
Jun 27 '08 #26

P: n/a
Harald van Dijk <tr*****@gmail.comwrites:
On Sun, 27 Apr 2008 18:52:20 +0530, santosh wrote:
>Ben Bacarisse wrote:
>>Harald van D?k <tr*****@gmail.comwrites:
On Sun, 27 Apr 2008 13:36:20 +0100, Ben Bacarisse wrote:
santosh <sa*********@gmail.comwrites:
>Maybe jacob implemented -ansi89 switch as a synonym for -ansi?
>
Sorry, I don't follow.

With GCC, -ansi means that valid C90 programs will be accepted, but
invalid C90 programs, complete with syntax errors and/or constraint
violations, will not necessarily be rejected. It's possible that jacob
navia made -ansi89 behave the same way in lcc-win32.

I considered that meaning, but since santosh was replying to a message
that stated that -ansi89 treats restrict as a keyword, that did not
seem like a reasonable interpretation.

Yes. The lcc-win manual that I have indicates that the -ansi switch
makes the compiler conform to C99. [...]

Interesting. I still happened to have the Linux version of lcc installed,
and it doesn't support any -ansi option, but does support the -ansi89
option.

Warning 0 Ignoring unknown option '-ansi'

Because of that, I didn't consider the possibility of an lcc option -ansi
since added.
It hasn't been added. I think santosh is referring to the -ansic flag.

--
Ben.
Jun 27 '08 #27

P: n/a
Harald van Dijk wrote, On 27/04/08 13:42:
On Sun, 27 Apr 2008 13:36:20 +0100, Ben Bacarisse wrote:
>santosh <sa*********@gmail.comwrites:
>>Maybe jacob implemented -ansi89 switch as a synonym for -ansi?
Sorry, I don't follow.

With GCC, -ansi means that valid C90 programs will be accepted, but
invalid C90 programs, complete with syntax errors and/or constraint
violations, will not necessarily be rejected. It's possible that jacob
navia made -ansi89 behave the same way in lcc-win32.
I believe that on lcc-win32 -ansic selects C99 conformance (modulo bugs
and bits not implemented). So if -ansi99 was a synonym for -ansic it
would also select C99 conformance and thus allow // comments, treat
restrict as a keyword etc.
--
Flash Gordon
Jun 27 '08 #28

P: n/a
santosh <sa*********@gmail.comwrites:
Ben Bacarisse wrote:
>Harald van D?k <tr*****@gmail.comwrites:
>>On Sun, 27 Apr 2008 13:36:20 +0100, Ben Bacarisse wrote:
santosh <sa*********@gmail.comwrites:
Maybe jacob implemented -ansi89 switch as a synonym for -ansi?

Sorry, I don't follow.

With GCC, -ansi means that valid C90 programs will be accepted, but
invalid C90 programs, complete with syntax errors and/or constraint
violations, will not necessarily be rejected. It's possible that
jacob navia made -ansi89 behave the same way in lcc-win32.

I considered that meaning, but since santosh was replying to a message
that stated that -ansi89 treats restrict as a keyword, that did not
seem like a reasonable interpretation.

Yes. The lcc-win manual that I have indicates that the -ansi switch
You mean -ansic yes?
makes the compiler conform to C99. Your post up-thread which seemed to
indicate that lcc-win accepted several C99 constructs when
under -ansi89 suggested to me that jacob might have simply made -ansi89
a synonym for -ansi with a few more check (presumably whatever his
paying customer asked for) added in.
No. It does, for example stop inline being a keyword and stops
declarations being mixed with statements.
This would mean that -ansi89 isn't
really suitable for making lcc-win conform to C90. This is also borne
out by the fact that the -ansi89 switch isn't listed in the lcc-win
manual I have here.
Jacob seems to be saying that it is a custom flag for one particular
purpose. As such, it seems that lcc-win32 has no C90/C89 conforming
mode and the specific tests made when -ansi89 are given were selected
by a customer and don't have much to do with the standard.

--
Ben.
Jun 27 '08 #29

P: n/a
Ben Bacarisse wrote:
santosh <sa*********@gmail.comwrites:
[ ... ]
>Yes. The lcc-win manual that I have indicates that the -ansi switch

You mean -ansic yes?
Sorry yes. Time for another cup of tea. :-)
>makes the compiler conform to C99. Your post up-thread which seemed
to indicate that lcc-win accepted several C99 constructs when
under -ansi89 suggested to me that jacob might have simply made
-ansi89 a synonym for -ansi with a few more check (presumably
whatever his paying customer asked for) added in.

No. It does, for example stop inline being a keyword and stops
declarations being mixed with statements.
Okay, but if it is intended to be a generally usable option then jacob
needs to do more work.
>This would mean that -ansi89 isn't
really suitable for making lcc-win conform to C90. This is also borne
out by the fact that the -ansi89 switch isn't listed in the lcc-win
manual I have here.

Jacob seems to be saying that it is a custom flag for one particular
purpose. As such, it seems that lcc-win32 has no C90/C89 conforming
mode and the specific tests made when -ansi89 are given were selected
by a customer and don't have much to do with the standard.
This is my impression too. Also if (as it seems to me) jacob has not
documented the -ansi89 switch anywhere, and it was meant only for a
specific customer, I wonder how the OP stumbled on it. I guess he just
happened to use -ansi89 and saw that it was accepted.

It would be helpful if jacob could clarify things further, perhaps in
comp.compilers.lcc.

Jun 27 '08 #30

P: n/a
santosh wrote:
Ben Bacarisse wrote:
>santosh <sa*********@gmail.comwrites:
[ ... ]
>>Yes. The lcc-win manual that I have indicates that the -ansi switch
You mean -ansic yes?

Sorry yes. Time for another cup of tea. :-)
>>makes the compiler conform to C99. Your post up-thread which seemed
to indicate that lcc-win accepted several C99 constructs when
under -ansi89 suggested to me that jacob might have simply made
-ansi89 a synonym for -ansi with a few more check (presumably
whatever his paying customer asked for) added in.
No. It does, for example stop inline being a keyword and stops
declarations being mixed with statements.

Okay, but if it is intended to be a generally usable option then jacob
needs to do more work.
>>This would mean that -ansi89 isn't
really suitable for making lcc-win conform to C90. This is also borne
out by the fact that the -ansi89 switch isn't listed in the lcc-win
manual I have here.
Jacob seems to be saying that it is a custom flag for one particular
purpose. As such, it seems that lcc-win32 has no C90/C89 conforming
mode and the specific tests made when -ansi89 are given were selected
by a customer and don't have much to do with the standard.

This is my impression too. Also if (as it seems to me) jacob has not
documented the -ansi89 switch anywhere, and it was meant only for a
specific customer, I wonder how the OP stumbled on it. I guess he just
happened to use -ansi89 and saw that it was accepted.

It would be helpful if jacob could clarify things further, perhaps in
comp.compilers.lcc.
Really, you think it would be fun to work for making my compiler system
refuse // comments?

If Mr "teapot" pays me 1 day consulting I would do it, but just for the
fun of the regulars here?

I added the ansi89 flag for a specific customer. I thought some people
would be happy to see the C99 dependencies in their code. OK. But I
haven't a team of people like gcc, so it is just impossible to do now.

Of course if the regulars PAY for it it *could* be done.

:-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jun 27 '08 #31

P: n/a
jacob navia wrote, On 27/04/08 16:10:
santosh wrote:
>Ben Bacarisse wrote:
>>santosh <sa*********@gmail.comwrites:
<snip>
>>>This would mean that -ansi89 isn't
really suitable for making lcc-win conform to C90. This is also borne
out by the fact that the -ansi89 switch isn't listed in the lcc-win
manual I have here.
Jacob seems to be saying that it is a custom flag for one particular
purpose. As such, it seems that lcc-win32 has no C90/C89 conforming
mode and the specific tests made when -ansi89 are given were selected
by a customer and don't have much to do with the standard.

This is my impression too. Also if (as it seems to me) jacob has not
documented the -ansi89 switch anywhere, and it was meant only for a
specific customer, I wonder how the OP stumbled on it. I guess he just
happened to use -ansi89 and saw that it was accepted.

It would be helpful if jacob could clarify things further, perhaps in
comp.compilers.lcc.

Really, you think it would be fun to work for making my compiler system
refuse // comments?
Santosh says the switch is undocumented. If this is the case then it
doesn't matter what it does and anyone who "stumbles across it" and uses
it deserves anything that get.
If Mr "teapot" pays me 1 day consulting I would do it, but just for the
fun of the regulars here?

I added the ansi89 flag for a specific customer.
If it does what that customer wants (and that is between you and the
customer, not us) then fine.
I thought some people
would be happy to see the C99 dependencies in their code. OK.
Well, as has been pointed out it at most shows *some* C99 dependencies,
not all.
But I
haven't a team of people like gcc, so it is just impossible to do now.

Of course if the regulars PAY for it it *could* be done.

:-)
As this is unlikely just leave the switch undocumented or documented as
not being fully conforming. Then there is nothing for anyone here to
complain about with regards to that switch.
--
Flash Gordon
Jun 27 '08 #32

P: n/a
ym******@gmail.com wrote:
>
.... snip ...
>
Actually I was wrong, I have no idea if there was a C
compiler which didn't understand // comments. By the time
when a compiler got to C90 conformance (N years after 1990),
// comments were probably already there. What conforming C90
compiler doesn't understand // comments? Just curious.
ANY conforming C90 compiler doesn't understand // comments.
Otherwise it isn't a conforming C90 compiler.

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

P: n/a
On Sun, 27 Apr 2008 12:59:17 -0400, CBFalconer wrote:
ym******@gmail.com wrote:
>>
... snip ...
>>
Actually I was wrong, I have no idea if there was a C compiler which
didn't understand // comments. By the time when a compiler got to C90
conformance (N years after 1990), // comments were probably already
there. What conforming C90 compiler doesn't understand // comments?
Just curious.

ANY conforming C90 compiler doesn't understand // comments. Otherwise it
isn't a conforming C90 compiler.
A conforming C90 compiler is allowed to understand // comments in those
situations where they would otherwise be syntax errors.

But I think ymuntyan's question is whether any conforming C90 compiler
has no other mode (whether conforming or nonconforming) where // comments
are accepted.
Jun 27 '08 #34

P: n/a
Harald van D?k wrote:
On Sun, 27 Apr 2008 12:59:17 -0400, CBFalconer wrote:
>ym******@gmail.com wrote:
>>>
... snip ...
>>>
Actually I was wrong, I have no idea if there was a C compiler which
didn't understand // comments. By the time when a compiler got to
C90 conformance (N years after 1990), // comments were probably
already there. What conforming C90 compiler doesn't understand //
comments? Just curious.

ANY conforming C90 compiler doesn't understand // comments. Otherwise
it isn't a conforming C90 compiler.

A conforming C90 compiler is allowed to understand // comments in
those situations where they would otherwise be syntax errors.
Did you mean situations where they would otherwise not be syntax errors?

<snip>

Jun 27 '08 #35

P: n/a
Harald van Dijk <tr*****@gmail.comwrites:
On Sun, 27 Apr 2008 12:59:17 -0400, CBFalconer wrote:
>ym******@gmail.com wrote:
>>>
... snip ...
>>>
Actually I was wrong, I have no idea if there was a C compiler which
didn't understand // comments. By the time when a compiler got to C90
conformance (N years after 1990), // comments were probably already
there. What conforming C90 compiler doesn't understand // comments?
Just curious.

ANY conforming C90 compiler doesn't understand // comments. Otherwise it
isn't a conforming C90 compiler.

A conforming C90 compiler is allowed to understand // comments in those
situations where they would otherwise be syntax errors.
But it must still diagnose those syntax errors.

[...]

--
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"
Jun 27 '08 #36

P: n/a
On Mon, 28 Apr 2008 00:26:50 +0530, santosh wrote:
Harald van D?k wrote:
>A conforming C90 compiler is allowed to understand // comments in those
situations where they would otherwise be syntax errors.

Did you mean situations where they would otherwise not be syntax errors?
No, in those situations, it is specifically not allowed to understand //
comments.

A conforming C90 compiler must make

int main(void) {
return 1 //* hello, world! */
+ 2;
}

return 0. A conforming C99 compiler must make it return 3 (whatever that
means), and a nonconforming C90-based compiler that accepts // comments
as an extension typically does the same.

A conforming C90 compiler may accept

int main(void) {
return 0; // hello, world!
}

(provided it diagnoses the syntax error, as pointed out by Keith
Thompson), and this is what I was referring to.
Jun 27 '08 #37

P: n/a
Harald van D?k wrote:
On Mon, 28 Apr 2008 00:26:50 +0530, santosh wrote:
>Harald van D?k wrote:
>>A conforming C90 compiler is allowed to understand // comments in
those situations where they would otherwise be syntax errors.

Did you mean situations where they would otherwise not be syntax
errors?

No, in those situations, it is specifically not allowed to understand
// comments.

A conforming C90 compiler must make

int main(void) {
return 1 //* hello, world! */
+ 2;
}

return 0. A conforming C99 compiler must make it return 3 (whatever
that means), and a nonconforming C90-based compiler that accepts //
comments as an extension typically does the same.

A conforming C90 compiler may accept

int main(void) {
return 0; // hello, world!
}

(provided it diagnoses the syntax error, as pointed out by Keith
Thompson), and this is what I was referring to.
okay, thanks for the clarification.

Jun 27 '08 #38

P: n/a
On Apr 27, 1:11*am, jacob navia <ja...@nospam.comwrote:
Ben Bacarisse wrote:
jacob navia <ja...@nospam.comwrites:
Recently we had poor Mr "teapot" that was horrified at the heresy
of lcc-win of accepting // comments.
Can you clear up the question of what the -ansi89 flag is intended to
do? *Your compiler is allowed to accept any extensions it likes and to
reject and conforming C90 programs it wishes to *unless* you claim that
lc -ansi89 is intended to be a conforming C90 implementation. *What is
the purpose of -ansi89?

-ansi89 was implemented to the wishes of a paying customer. They wanted
a compiler to that standard, and I implemented it for them. The usage of
that flag is to disable most C99 stuff.

Note that many compilers at the C89 level accept // comments, for instance
Microsoft compilers

Actually with "-Za -W4" MSVC2005 emits:

"test49.c(7) : warning C4001: nonstandard extension 'single line
comment' was used"
Jun 27 '08 #39

P: n/a
On Apr 27, 7:07 am, ymunt...@gmail.com wrote:
On Apr 27, 6:02 am, ymunt...@gmail.com wrote:
On Apr 27, 4:26 am, Flash Gordon <s...@flash-gordon.me.ukwrote:
jacob navia wrote, On 27/04/08 08:59:
Richard Heathfield wrote:
Keith Thompson said:
>jacob navia <ja...@nospam.comwrites:
<snip>
>>Note that many compilers at the C89 level accept // comments,
If they are invoked in conforming mode, they *must* diagnose syntax
errors.
Maybe. If they do not, please use another compiler.
If you state that -ansi89 does *not* mean conformance to C89 (or C90 or
C95) then as has already been stated it is allowed to accept whatever
you want. If I was one of your paying customers I would not be happy,
but I'm not.
Perhaps that customer wanted warnings for stuff which
reduces portability, like variadic macros not understood
by MS compiler?
(Yes I do realize that where were, and hence are, C compilers
which do not understand // comments)

Actually I was wrong, I have no idea if there was a C
compiler which didn't understand // comments. By the time
when a compiler got to C90 conformance (N years after 1990),
// comments were probably already there. What conforming C90
compiler doesn't understand // comments? Just curious.

Yevgen


Well, strictly speaking no conforming C90 compiler can "understand"
// comments (see elsethread for more details). However, if your
question
is "is there a conforming compiler which cannot be invoked in a mode
in
which it understands // comments" then I do not know of one, and
certainly
the most popular compilers do have a mode in which // is understood.
What they do not have is a mode in which the only extension understood
is //
comments. So if you use // comments you can no longer use these
compilers
in a conforming mode.
- William Hughes
Jun 27 '08 #40

P: n/a
William Hughes wrote:
<snip>
Well, strictly speaking no conforming C90 compiler can "understand"
// comments (see elsethread for more details). However, if your
question
is "is there a conforming compiler which cannot be invoked in a mode
in
which it understands // comments" then I do not know of one, and
certainly
the most popular compilers do have a mode in which // is understood.
What they do not have is a mode in which the only extension understood
is //
comments.
I know one such compiler (hmm, actually two), it
uses -Wallow_cplusplus_comments for that and only for that.
So if you use // comments you can no longer use these
compilers
in a conforming mode.
Not quite so...

Bye, Jojo
Jun 27 '08 #41

This discussion thread is closed

Replies have been disabled for this discussion.