Re: [OT] lcc first experience

jacob navia <jacob@[EMAIL PROTECTED]
> writes:
> Richard Heathfield wrote:
>> Harald van D?k said:
>>> On Thu, 08 May 2008 13:45:24 -0400, CBFalconer wrote:
>>>> If you ever actually try "-W -Wall -ansi -pedantic" on gcc, you will
>>>> discover that (barring possible errors) it doesn't
embrace-and-extend.
>>> This translation unit is accepted without any diagnostic by gcc -W
-Wall
>>> - ansi -pedantic:
>>>
>>> int __attribute__((const)) zero(void) { return 0; }
>>>
>>> Does that mean the code is valid C, that this is an error in GCC, or
that
>>> GCC does embrace-and-extend?
>>
>> Implementations are permitted to provide extensions that do not
>> affect the behaviour of a strictly conforming program. The above
>> code is not strictly conforming.
>
> Of course if implementations are called "lcc-win" you will start ranting
> with no end.
>
> It took me an enormous effort to implement my extensions without adding
> any new keywords, making them 100% compatible with the C standard.
>
> I was  always told that "I am forced to emit a diagnostic at non
> conforming code", that I am non standard etc etc. But obviously for
> gcc you use other criteria!
>
> gcc can do whatever it wants because it is GNU and linux, and that is
> good.
>
> lcc-win is windows and non GNU hence it is bad.
>
> Period.

To the best of my recollection, neither gcc nor lcc-win has been
flamed for providing extensions that do not affect the behavior of
strictly conforming programs such as gcc's __attribute__ or lcc-win's
operator overloading.  (I'm assuming that lcc-win's operator
overloading doesn't break strictly conforming code.)

The standard does not require a diagnostic for the use of
__attribute__, therefore we have no problem with the lack of a
diagnostic.  (IMHO it would be nice if gcc had a "really pedantic"
mode in which it does diagnose such things, but I'm not going to
insist on it.)

If a gcc developer repeatedly advocated the use of
__attribute__((const)) in comp.lang.c, that developer would
undoubtedly be flamed for it, and asked to take his advocacy
elsewhere.

lcc-win does not conform to C90, and does not claim to do so.  That's
not a problem.  When the existence of the undo***ented "-ansic89"
option recently came to light, and it was found that it did not cause
lcc-win to conform to C89/C90 requirements, a lengthy discussion
ensued -- one that could have been cut short if you had simply
mentioned that "-ansic89" is not intended to implement C89/C90
conformance.

lcc-win declares several non-standard identifiers in its standard
headers ("wtof" was the most recent example).  This breaks strictly
conforming programs.  I consider these to be minor bugs, easy to fix
-- and, given the knowledge of the standard that I would expect from a
compiler developer, trivially easy to avoid in the first place.  You
have been mildly criticized for these bugs; you have been flamed for
reacting to bug re****ts as if they were vicious personal attacks.  If
your response had been something like "Thanks for pointing that out;
I'll fix it in the next release", or even "... I'll fix it when I get
around to it", there would have been no real problem, at least as far
as I'm concerned.

You have been one of the most vociferous advocates of adopting the C99
standard and discarding the (officially obsolete) C90 standard, in
spite of the fact that the C99 standard is not yet sufficiently widely
implemented to make C99 code ****table.  This is an odd attitude in
view of the fact that your own lcc-win's C99 conformance is flawed,
not just by bugs but by missing features.

Yes, you and your compiler have been criticized here in ways that gcc
and its developers have not.  Part of this may be due to a general
pro-gcc bias, but I believe the majority of the criticisms have been
of things that *don't apply* to gcc.

-- 
Keith Thompson (The_Other_Keith) <kst-u@[EMAIL PROTECTED]
>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"