jacob navia said:
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 undocumented "-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 reports 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 portable. 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.