Serious conformance BUG in lcc-win32 still present

[Tea Pot]

Almost a year ago a BUG was pointed out in this group that the lcc-win32
compiler of so-called "C" will "accept" C++-style comments even when it's
run with the -ansi89 switch to ALLEGEDLY make it C90 conforming. No
diagnostic is produced.

This BUG is still present.

If the maintainer of lcc-win32 is serious about making a
standards-conforming compiler, he should address this BUG as a matter of
urgency.

Thank you.

 

[user923005]

Almost a year ago a BUG was pointed out in this group that the lcc-win32
compiler of so-called "C" will "accept" C++-style comments even when it's
run with the -ansi89 switch to ALLEGEDLY make it C90 conforming. No
diagnostic is produced.

This BUG is still present.

If the maintainer of lcc-win32 is serious about making a
standards-conforming compiler, he should address this BUG as a matter of
urgency.

What specific harm is resulting from this defect?

 

[Lew Pitcher]

What specific harm is resulting from this defect?

As a guess, improper evaluation of statements like...

a = 10 //*divide*/2 + 7
;
;-)

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

 

[gw7rib]

What specific harm is resulting from this defect?

Perhaps they're writing programs, testing them out on their systems,
and then shipping the source code to their important customer, who
then finds it fails to compile on his C90 compiler?

 

[Keith Thompson]

Almost a year ago a BUG was pointed out in this group that the lcc-win32
compiler of so-called "C" will "accept" C++-style comments even when it's
run with the -ansi89 switch to ALLEGEDLY make it C90 conforming. No
diagnostic is produced.

This BUG is still present.

If the maintainer of lcc-win32 is serious about making a
standards-conforming compiler, he should address this BUG as a matter of
urgency.

Did you have a question about the C programming language?

If you have a problem with lcc-win32, I suggest you post to
comp.compilers.lcc and/or contact the maintainer directly.

(If I recall correctly from earlier dicussions, the "-ansi89"
switch isn't even documented, much less guaranteed to make the
compiler C90 conforming. If that's the case, I don't see that you
have any grounds for complaint. But of course that's between you
and the lcc-win32 maintainer.)

Frankly, it seems unlikely that this non-conformance would seriously
inconvenience you.

 

[robertwessel2]

What specific harm is resulting from this defect?

It's a pretty minor bug, but there are some pathological cases where C+
+ style comments can alter the meaning of C code. Consider:

a = b //* xxx */
+3;

Depending on how "//" is interpreted, that will either add three or
divide by three.

 

[user923005]

It's a pretty minor bug, but there are some pathological cases where C+
+ style comments can alter the meaning of C code.  Consider:

a = b //* xxx */
+3;

Depending on how "//" is interpreted, that will either add three or
divide by three.

Sure, but if that is the customer's actual problem, he's got bigger
issues to deal with.

 

[Bartc]

Almost a year ago a BUG was pointed out in this group that the lcc-win32
compiler of so-called "C" will "accept" C++-style comments even when it's
run with the -ansi89 switch to ALLEGEDLY make it C90 conforming. No
diagnostic is produced.

This BUG is still present.

If the maintainer of lcc-win32 is serious about making a
standards-conforming compiler, he should address this BUG as a matter of
urgency.

The maintainer of lcc-win32 makes his compiler available for free. So he can
do what he likes, unless you want to pay him to fix the 'problem'.

 

[user923005]

The maintainer of lcc-win32 makes his compiler available for free. So he can
do what he likes, unless you want to pay him to fix the 'problem'.

Perhaps the OP has purchased support. At any rate, the lcc forum
seems better than here, and private correspondence most sensible of
all.

 

[jacob navia]

Almost a year ago a BUG was pointed out in this group that the lcc-win32
compiler of so-called "C" will "accept" C++-style comments even when it's
run with the -ansi89 switch to ALLEGEDLY make it C90 conforming. No
diagnostic is produced.

This BUG is still present.

If the maintainer of lcc-win32 is serious about making a
standards-conforming compiler, he should address this BUG as a matter of
urgency.

Thank you.

Mr "Tea Pot"

Having searched my database of registered customers, I did not find your
payment. You are not entitled to support.

I implemented this "ansi89" flag for a paying customer some years ago,
and it is not part of the public interface. He payed me 3 full days of
consulting for certain specific requirements, and not handling "//"
comments was NOT one of them.

Yours sincerely

 

[CBFalconer]

What specific harm is resulting from this defect?

The user is unable to determine that his code is suitable for C90.
Do you want to manually edit 20k lines looking for a // comment?
Especially code written by people who economize on blanks.

 

[user923005]

The user is unable to determine that his code is suitable for C90.
Do you want to manually edit 20k lines looking for a // comment?
Especially code written by people who economize on blanks.

How hard is it to compile the mess with GCC?

 

[Keith Thompson]

The user is unable to determine that his code is suitable for C90.
Do you want to manually edit 20k lines looking for a // comment?
Especially code written by people who economize on blanks.

It should take a few seconds to search for "//", plus no more than a
few minutes to check each occurrence to see whether it's a comment
delimiter (as opposed to part of a string literal, part of a comment,
or a few other unlikely possibilities). I fail to see what
economizing on blanks has to do with it.

(I just tried this on the sources for GNU tar. The *.h and *.c files
total 19241 lines. "grep // *.h *.c" took almost too little time to
measure, and produced 3 lines of output, all of which were
"http://..." references in comments.)

The real question, I think, is what specific harm has resulted *to the
original poster*, something that he hasn't seen fit to tell us.
Another question is what obligation jacob has to do anything about
this; as far as I can tell, the answer to that is "none whatsoever".

In a compiler whose documentation claims that it conforms to C90,
accepting // comments would be a serious conformance problem (though
working around it would not be difficult). But since jacob has not
claimed that lcc-win32 conforms to C90, and has not even documented
the "-ansi89" switch, that's not relevant.

 

[Guest]

Perhaps they're writing programs, testing them out on their systems,
and then shipping the source code to their important customer, who
then finds it fails to compile on his C90 compiler?

write a tool that detects // comments and add it to their
toolchain. Good grief.

 

[Kenny McCormack]

The maintainer of lcc-win32 makes his compiler available for free. So he can
do what he likes, unless you want to pay him to fix the 'problem'.

It is pretty obvious that "Tea Pot" is Heathfield or some other reg's
sock puppet.

 

[Richard]

It is pretty obvious that "Tea Pot" is Heathfield or some other reg's
sock puppet.

Flash Gordon no doubt. Or CBF ....

 

[Tea Pot]

Mr "Tea Pot"

Having searched my database of registered customers, I did not find your
payment. You are not entitled to support.

I implemented this "ansi89" flag for a paying customer some years ago,
and it is not part of the public interface. He payed me 3 full days of
consulting for certain specific requirements, and not handling "//"
comments was NOT one of them.

It is a vicious circle. I definitely won't appear on a "database of
registered customers" until you take standards conformance seriously.

I think your attitude is very bad. You should act on BUG reports received
from ordinary users as well as registered users. Don't you have any pride
in your work? Why don't you care that it has serious problems? Is money
the only thing that matters, and you don't mind if what you produce is a
load of crap as long as you get paid?

Following the C Standard should be a basic builtin feature of any C
compiler, it shouldn't be something people have to pay extra for at
consulting rates.

Please consider fixing this BUG quickly.

Thank you.

 

[Tea Pot]

Did you have a question about the C programming language?

Don't you care about support for Standard C from compiler vendors? I post
to this group because I believe many people here are interested in
standards compliance, even though it seems to have been taken over by
trolls who don't care about standards.

If you have a problem with lcc-win32, I suggest you post to
comp.compilers.lcc and/or contact the maintainer directly.

(If I recall correctly from earlier dicussions, the "-ansi89"
switch isn't even documented, much less guaranteed to make the
compiler C90 conforming. If that's the case, I don't see that you
have any grounds for complaint. But of course that's between you
and the lcc-win32 maintainer.)

Frankly, it seems unlikely that this non-conformance would seriously
inconvenience you.

It may seem like a trivial point, but is indicative of the attitude of the
vendor who seems not to care about standards, conformance and portability.
Fixing this glaring BUG would be a sign to everyone that lcc-win32 seeks
to be standards compliant.

 

[user923005]

Don't you care about support for Standard C from compiler vendors? I post
to this group because I believe many people here are interested in
standards compliance, even though it seems to have been taken over by
trolls who don't care about standards.

I guess that Keith cares about standards more than average, which is a
lot.

It may seem like a trivial point, but is indicative of the attitude of the
vendor who seems not to care about standards, conformance and portability..
Fixing this glaring BUG would be a sign to everyone that lcc-win32 seeks
to be standards compliant.

I don't see what the big problem is.
grep // *.c > newcmnt.dat
seems to solve the problem, without a whole lot of fuss.
I guess that if his paying customers asked for it, then he would
implement detection of // comments.

Speaking of tea pot, this is a tempest in a tea pot. So I get the
joke, OK.

 

[jameskuyper]

Tea Pot wrote:
....

I think your attitude is very bad. You should act on BUG reports received
from ordinary users as well as registered users. Don't you have any pride
in your work? Why don't you care that it has serious problems? Is money
the only thing that matters, and you don't mind if what you produce is a
load of crap as long as you get paid?

No, he has pride in producing a non-conforming compiler, because he
considers the way in which it fails to conform to constitute an
improvement over the behavior of a fully-conforming compiler. It
follows quite naturally that he doesn't consider the non-conformance
to be a serious problem. He minds very much what he produces, and does
not want to produce what he would consider a "load of crap" , which is
precisely how he would feel about producing a fully-conforming
implementation of C90 (though I have no idea whether he'd use that
particular phrase to describe his attitude).

His target customer base doesn't care any more than he does about this
non-conformance. So why does it matter to you?

Following the C Standard should be a basic builtin feature of any C
compiler, it shouldn't be something people have to pay extra for at
consulting rates.

That attitude clearly marks you as not a member of his target customer
base. So don't use it. You've got lots of alternatives.

The only argument I've every had with him about this issue is about
whether or not he's actually claiming conformance that doesn't exist,
and whether his non-conforming implementation is topical on this
newsgroup. He has every right to produce a non-conforming
implementation if that's what he wants to do.