[OT] lcc first experience

[Spiros Bousbouras]

This translation unit is accepted without any diagnostic by gcc -W -Wall -
ansi -pedantic:

int __attribute__((const)) zero(void) { return 0; }

Not related to your point but I tried the above code
with splint , c99 and c89 from Sun Studio 12. None
of the tools produced any warnings. To be precise
with the compilers (including gcc) you have to add
the -c option otherwise they complain about the lack
of main().

 

[Antoninus Twink]

Surely the amount of difficulty in writing a conforming
C compiler will be increased by adding extensions. Your
last sentence seems to suggest otherwise.

Are you being deliberately obtuse, or are you just trying to fit in with
the stupid literalism that's all the vogue in clc?

A compiler is, by definition, system specific. It doesn't exist in a
vacuum, but is a C program's link to the underlying system. Of course
extensions will be necessary if the program is to make best use of the
system it's running on.

The C standard describes an abstract machine. The fact that many posters
to this newsgroup treat it with a fetishistic reverence and try to make
it into something it isn't doesn't change the reality. If you're happy
to write trivial little homework-type programs, then fine, use strictly
conforming standard C. If you're interested in writing C programs in the
real world, then get real.

 

[Harald van Dijk]

A compiler is, by definition, system specific. It doesn't exist in a
vacuum, but is a C program's link to the underlying system. Of course
extensions will be necessary if the program is to make best use of the
system it's running on.

I meant it's extremely difficult to write a conforming C compiler that
doesn't provide extensions. I hadn't meant to imply anything about the
source code of the compiler. Now that you brought it up though, not all
extensions are a good idea, if you want to be able to compile the compiler
on a system that doesn't already have it.

 

[Keith Thompson]

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.

 

[Antoninus Twink]

This translation unit is accepted without any diagnostic by
gcc -W -Wall - ansi -pedantic:

I think '- ansi' is not a legal signal to gcc. [snip]

int __attribute__((const)) zero(void) { return 0; }

Well, I got:

[1] c:\c\junk>gcc junk.c
c:/djgpp/lib/crt0.o:crt0.s.data+0xc2): undefined reference to
`_main'
c:/djgpp/lib/libc.a(crt1.o):crt1.c.text+0x404): undefined
reference to `_main'

collect2: ld returned 1 exit status

Are you a professional moron, or just a gifted amateur?

 

[Harald van Dijk]

I think '- ansi' is not a legal signal to gcc.

That should have been -ansi, which is what I typed but pan's word wrapping
changed. If you look back at my message, you will find that - appeared at
the end of a line, and ansi appeared at the start of the next.

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?

[snip]
BTW, __attribute__ is in the implementors namespace.

What made you think I was unaware of that? The fact that it's an allowed
extension doesn't make it any less of an extension.

 

[Ben Bacarisse]

It took me a LOT of effort to implement ALL my extensions without
introducing ANY keywords, as the standard requires.

I don't think the standard makes any such requirement.

When gcc does the same in a MUCH more intrusive way, then it is OK of
course, even if the -ansi flag is present!

Well I won't repeat why it is OK but I must disagree that it is much
more intrusive. The syntax was designed so that it can be very simply
removed (gcc '-D__attribute__(x)=' does it from the command line) or,
if I need to see where it may have been used (because I am porting to
a system that uses the same syntax for something else) I can force a
syntax error -- even from the command line if need be (gcc
'-D__attribute__(x)={+}' would probably do it).

 

[Antoninus Twink]

Jacob, it's been twenty-four hours since you were asked to produce
just one example of my endless ranting about conforming extensions in
your compiler. Can you provide an update on your progress?
Investigations going smoothly, I presume? When may we expect results?

Eric, you really can be a total dick sometimes.

Here are a couple of characteristic messages from long threads in the
past few months. I'm sure if you trawl through the archives you'll find
many, many more examples of occasions when you've jumped on the
anti-Jacob bandwagon.


==

Message-ID: <1191450640.668151@news1nwk>
Is this the same debugger about which you said "Without [garbage
collection], I would never have finished?"

Let's see: You've already described C's lack of operator overloading as
evidence of neglect on the part of the committee, you've characterized
__declspec(naked) as an important language feature you use "very often,"
you've railed at the absence of fixed-point arithmetic, ... Is there
any feature, doodad, or dingbat you think *isn't* essential to C's
survival?

==

Message-ID: <[email protected]>

Finally, operator overloading is by no means the only fad you promote.
Your exact words were "many things that are necessary in a modern
software development environment," with no limitation on or
characterization of all these so-called "necessities." The sole
mechanism you suggest for deciding whether something would or would not
be a useful change to the language is "Whatever Jacob is enthusiastic
about is an `advance' and goes into Jacob's compiler, which should by
rights be the reference implementation for and definition of C." Pfui!

 

[Old Wolf]

I do not know why this is not used elsewhere.

The Metaware C compiler for ARM allows this syntax:
0x2x1000000;

where the bit between the two x's is the base (in hex).

 

[Richard Bos]

If you ever actually try "-W -Wall -ansi -pedantic" on gcc, you
will discover that (barring possible errors) it doesn't
embrace-and-extend.

YM it can be made not to. Ganuck as a language does; and Gnu programs as
a body do very much so.

Richard

 

[Richard Bos]

Gcc can do anything, like MSVC.

If I add some extension, I will be flamed of course.

jacob, jacob, jacob... your paranoia is running away with you again. I
specifically said upthread that you are _a disciple of_ Ganoo and M$,
IOW, as bad as, not worse than.

Richard