good c compiler

[Antoninus Twink]

I've been a bit snowed under today, so I didn't have time to predict
that you'd ignore the issue in favour of swapping fatuous remarks with
trolls.

You have made a claim. You've been asked to back it up. You've failed.
Same ol' same ol'.

Do you really blame him?

Jacob has explained over and over again, but *of course* you refuse to
listen, you deliberately misunderstand, you play your famous word games.

Why should he waste any more of his time when he knows what bad faith
there is on your part?

Why are you so full of hate and anger, Heathfield? Did you have an
unhappy childhood? You should think about therapy.

 

[jacob navia]

Do you really blame him?

Jacob has explained over and over again, but *of course* you refuse to
listen, you deliberately misunderstand, you play your famous word games.

Why should he waste any more of his time when he knows what bad faith
there is on your part?

Exactly.

Why are you so full of hate and anger, Heathfield? Did you have an
unhappy childhood? You should think about therapy.

Valium?

 

[jacob navia]

jacob navia said:


Let's restore some context, shall we? You said, in message
<[email protected]>, "Heathfield will still spit nonsense
when my compiler makes a perfectly C99 compatible extension but
will not complain about other compilers modifying syntax to implement
design by contract."

Keith Thompson replied: "Name one instance in which Richard Heathfield has
complained about a "perfectly C99 compatible extension" provided by
lcc-win."

You have failed to do this.

Mr Heathfield.

It is strange that after all those years discussing in this group, you
tell me that I need to prove that you are always arguing against all the
extensions I have proposed, here and in comp.std.c.

Maybe you have changed your mind, since there was a discussion about
operator overloading several weeks ago, where you assumed a very
positive attitude, not at all the attitude of blind reject that I
experienced very often from you. I still remember discussions in
comp.std.c where you adopted a negative attitude from the start.

This is a good development actually, and I will not argue against you
in this case.

Mr Twink is, as usual, quite wrong. I don't hate anybody, and although I
won't deny that I get angry sometimes (who doesn't get angry on
occasion?), I'm not angry about the subject under discussion. I am,
however, puzzled as to why you think I'm against the idea of lcc-win32
providing language extensions, because I'm *not* against that idea at all.

Well, this is a good development, since I need the discussion about this
extensions because I am not able to do this alone, as I have said
several times here, and in comp.std.c.

I have been very busy with the implementation of designator initializers
to be able to finish this C99 stuff that I am still missing.

Right now I can't think of any compiler that doesn't provide extensions.
Why should lcc-win32 be any different?

Obviously you feel that I am against the idea of extensions, but I don't
understand why you feel that. If you have some evidence to support your
feeling, why not provide that evidence? If you don't, you can hardly be
surprised if people don't accept that there is any rational basis for that
belief.

Look, the evidence is in Google and in the dozens of discussions that
are archived there. Anyone can read that.

What is more interesting is your attitude now. And if your attitude is
as you say it is, that's the only thing that really matters. The rest is
just the past.

 

[lawrence.jones]

For some reason, jacob confusingly describes that situation by saying
that lcc doesn't implement "long double".

Because he's thinking as an implementor: "I've already implemented
32-bit floating-point arithmetic for float and 64-bit floating-point
arithmetic for double; I don't feel like implementing yet another kind
of floating-point arithmetic for long double, so I'll just use my 64-bit
implementation instead." In Jacob's mind, this lazy implementor has
just reused his double implementation instead of implementing long
double (correctly). While it's understandable in that context, you're
correct that it's very confusing to the rest of us.

 

[Ian Collins]

Mr Heathfield.

It is strange that after all those years discussing in this group, you
tell me that I need to prove that you are always arguing against all the
extensions I have proposed, here and in comp.std.c.

Which is different form "perfectly C99 compatible extensions".

What is more interesting is your attitude now. And if your attitude is
as you say it is, that's the only thing that really matters. The rest is
just the past.

If you two can get along, this will become a very quiet group.....

 

[s0suk3]

jacob navia said:





Let's restore some context, shall we? You said, in message
<[email protected]>, "Heathfield will still spit nonsense
when my compiler makes a perfectly C99 compatible extension but
will not complain about other compilers modifying syntax to implement
design by contract."

Keith Thompson replied: "Name one instance in which Richard Heathfield has
complained about a "perfectly C99 compatible extension" provided by
lcc-win."

You have failed to do this.



Mr Twink is, as usual, quite wrong. I don't hate anybody, and although I
won't deny that I get angry sometimes (who doesn't get angry on
occasion?), I'm not angry about the subject under discussion. I am,
however, puzzled as to why you think I'm against the idea of lcc-win32
providing language extensions, because I'm *not* against that idea at all..
Right now I can't think of any compiler that doesn't provide extensions.
Why should lcc-win32 be any different?

Obviously you feel that I am against the idea of extensions, but I don't
understand why you feel that. If you have some evidence to support your
feeling, why not provide that evidence? If you don't, you can hardly be
surprised if people don't accept that there is any rational basis for that
belief.

(Sebastian)
"For example, lcc-win doesn't conform, but it has the most useful set
of extensions I've ever seen on any compiler."

(Richard Heathfield, in reply to Sebastian)
"If it doesn't implement the language correctly, the extensions are a
moot point."

Anyway, I don't know why Jacob Navia keeps arguing with you about it.
He should know by now how pointless it is to try to make any sense out
of your words.

Sebastian

 

[jacob navia]

Which is different form "perfectly C99 compatible extensions".

As I have explained several times, the standard does not
forbid extensions. The only thing you can't do is to add a new
keyword. And none of my extensions adds a new keyword.

 

[jacob navia]

Because he's thinking as an implementor: "I've already implemented
32-bit floating-point arithmetic for float and 64-bit floating-point
arithmetic for double; I don't feel like implementing yet another kind
of floating-point arithmetic for long double, so I'll just use my 64-bit
implementation instead." In Jacob's mind, this lazy implementor has
just reused his double implementation instead of implementing long
double (correctly). While it's understandable in that context, you're
correct that it's very confusing to the rest of us.

I would never treat Dave Hanson of "lazy". I have a big respect
for him and for Chris Fraser, the authors of lcc.

If you take that out, you are right. I was thinking about the
implementation of long double as a distinct machine supported type.

 

[Flash Gordon]

jacob navia wrote, On 28/09/08 21:25:

As I have explained several times, the standard does not
forbid extensions.

People are not arguing with that.

The only thing you can't do is to add a new
keyword.

That is incorrect. The standard actually says:
| ... A conforming implementation may have extensions (including
| additional library functions), provided they do not alter the behavior
| of any strictly conforming program.3)

| 3) This implies that a conforming implementation reserves no
| identiï¬ers other than those explicitly reserved in this
| International Standard.

The bit about keywords is in the non-normative annex J as an example of
something that could render an implementation non-conforming.

And none of my extensions adds a new keyword.

Fine.

 

[Mark L Pappin]

As I have explained several times, the standard does not
forbid extensions.

But it _does_ forbid extensions *which change the effect of conforming
code*.

For example, allowing '**' as an exponentiation operator would
probably work OK, as (AFAICS) there's nowhere that two '*' characters
can appear side-by-side between two values of arithmetic type; but
allowing '+++' as your exponentiation operator would not be valid as
this sequence of characters can appear in conforming code between some
values of arithmetic type with a well-defined meaning (and that
meaning is not exponentiation).

For an extension to be valid I must be able to compose a piece of code
which contains no Undefined Behaviour that compiles when fed to a
compiler which implements NO extenstions, and it must compile and work
the same when fed to a compiler which implements that extension.

The only thing you can't do is to add a new keyword.

Sorry, you're wrong, twice here. There are a large number of things
you can not do when adding extensions; and you certainly _can_ add a
new keyword, provided it's spelled in a way that is currently reserved
for you the implementor to use, e.g. by starting with two underscores.

And none of my extensions adds a new keyword.

I don't recall that this has ever been disputed here, but it's not the
point.

mlp

 

[James Kuyper]

(Sebastian)
"For example, lcc-win doesn't conform, but it has the most useful set
of extensions I've ever seen on any compiler."

(Richard Heathfield, in reply to Sebastian)
"If it doesn't implement the language correctly, the extensions are a
moot point."

How does that constitute evidence that he opposes extensions? It's
evidence that he dislikes non-conforming implementations (an eminently
reasonable attitude, IMO), but the topic under discussion is "perfectly
conforming C99 extensions", not non-conforming implementations. Have you
confused those two concepts?

 

[James Kuyper]

jacob navia wrote:
....

As I have explained several times, the standard does not
forbid extensions. The only thing you can't do is to add a new
keyword. And none of my extensions adds a new keyword.

Any extension that has effect while the compiler is in conforming mode
must meet these requirements:

An extension cannot cause behavior inconsistent with that required by
the standard, when the standard imposes restrictions. In particular,
Where the behavior of the code is merely unspecified, and not undefined,
the standard explicitly or implicitly provides two or more possible
behaviors - an extension can change which behavior is chosen, but cannot
cause behavior that is not in the specified range. An extension cannot
suppress diagnostics that the standard defines as mandatory. Finally, an
extension cannot cause a program to be accepted that contains a #error
directive that survives conditional compilation.

Most extensions that do not render a compiler non-conforming are
triggered by the use of a #pragma, or by code constructs that render the
behavior of the program undefined, thereby giving the implementation
almost unlimited permission to do whatever the implementor wants it to
do. In particular, use of identifiers which are reserved to the
implementation is one simple way in which the behavior can become
undefined. There's no reason why such constructs cannot add a keyword,
particularly if the keyword itself is from the namespace reserved to the
implementation.

 

[bernard]

Nearly.

What does that mean? Is this what Richard Heathfield and s0suk3
are discussing? Does it accept older language only? What does not
work? I am still learning C and still write only text mode standard
C programs. Thanks for all replies.

 

[Keith Thompson]

I would never treat Dave Hanson of "lazy". I have a big respect
for him and for Chris Fraser, the authors of lcc.

If you take that out, you are right. I was thinking about the
implementation of long double as a distinct machine supported type.

But that's not what "long double" *means*.

 

[Keith Thompson]

What does that mean? Is this what Richard Heathfield and s0suk3
are discussing? Does it accept older language only? What does not
work? I am still learning C and still write only text mode standard
C programs. Thanks for all replies.

It means simply that lcc-win, to the best of my knowledge, does not
*fully* support the C99 standard. It may or may not support enough of
it for your purposes.

As I recall, some time ago jacob stated that lcc-win did not support
macros that take a variable number of arguments or certain forms of
initializers. He may have implemented these features since then, but
if so I haven't seen (or, to be honest, I may have forgotten) any
indication here or in comp.compilers.lcc.

More recently, jacob has written in this newsgroup:

I have worked years implementing C99, and I have now an
implementation that is not missing any important feature.

I don't know which features he considers unimportant. You'll have to
decide for yourself whether the remaining unimplemented features are
important to you (which means you'll first have to find out what they
are).

For more specific information about lcc-win, post to
comp.compilers.lcc or contact jacob directly. You should also be
aware that it's free only for non-commercial use (and please don't
rely on my description; read the actual license terms).

 

[James Kuyper]

What does that mean? Is this what Richard Heathfield and s0suk3
are discussing? Does it accept older language only? What does not
work? I am still learning C and still write only text mode standard
C programs. Thanks for all replies.

It doesn't fully conform to any version of the standard.

In the mode where it comes closest to conforming to C90, it supports as
extensions certain C99 features. In itself, this is not a problem,
conforming implementations are allowed to provide extensions. However,
at least diagnostic message is mandatory under C90 for some uses of most
of those features, and lcc-win does not generate those mandatory
diagnostics. It could be something as simple as "thank you for making
use of this wonderful extension"; the standard says nothing about the
contents of the diagnostic message; but a message of some kind is required.

It also does not fully conform to C99, I don't know the details. jacob
has decided to put a lot of work into certain extensions to C99, at the
expense of failing to completely conform. That's a legitimate business
decision, but it costs him the ability to claim full C99 conformance.

 

[jacob navia]

[...]
lcc-win is a good compiler. I know, since I wrote most of it.
Comes with good IDE+resource editor, compiler+linker+debugger.
Project management, utilities included.

Compiler has extensive math library. Language accepted is C99.
Nearly.

What does that mean? Is this what Richard Heathfield and s0suk3 are
discussing? Does it accept older language only? What does not work? I
am still learning C and still write only text mode standard C
programs. Thanks for all replies.

It doesn't fully conform to any version of the standard.

In the mode where it comes closest to conforming to C90, it supports as
extensions certain C99 features.

For instance, it accepts // comments. Isn't it that HORRIBLE?

In itself, this is not a problem,
conforming implementations are allowed to provide extensions. However,
at least diagnostic message is mandatory under C90 for some uses of most
of those features, and lcc-win does not generate those mandatory
diagnostics.

As I told you, it fails to emit a diagnostic. This is just legalese
that will be corrected as soon as a single customer requires this
legalese.

Until then, the code is correctly generated, and extensions are
accepted.

It could be something as simple as "thank you for making
use of this wonderful extension"; the standard says nothing about the
contents of the diagnostic message; but a message of some kind is required.

Well, no message. And to tell you the truth, I think nobody cares,
excepting language lawyers.

It also does not fully conform to C99, I don't know the details. jacob
has decided to put a lot of work into certain extensions to C99, at the
expense of failing to completely conform.

I have worked for years in this project, and C99 is supported with all
important features there. There may be a few things not done yet, but
they are relatively obscure. The only significant feature missing is
variable arguments in the preprocessor.

 

[Nick Keighley]

Download:http://www.cs.virginia.edu/~lcc-win.

I got an error when I tried to access the link.
I don't think its there anymore...

 

[Nick Keighley]

Download:http://www.cs.virginia.edu/~lcc-win.

ah! this link is wrong


*this* link is ok

 

[Chris Dollin]

Keith Thompson wrote:

[...]
lcc-win is a good compiler. I know, since I wrote most of it.
Comes with good IDE+resource editor, compiler+linker+debugger.
Project management, utilities included.

Compiler has extensive math library. Language accepted is C99.
Nearly.

What does that mean? Is this what Richard Heathfield and s0suk3 are
discussing? Does it accept older language only? What does not work? I
am still learning C and still write only text mode standard C
programs. Thanks for all replies.

It doesn't fully conform to any version of the standard.

In the mode where it comes closest to conforming to C90, it supports as
extensions certain C99 features.

For instance, it accepts // comments. Isn't it that HORRIBLE?

Yes, if you want C90 conformance. I don't see the problem: if I
want C90 conformance, I don't want // comments. Berate me all you
(non-specific you) wish for my premisitical desire for C90 conformance,
for /that is not your (non-specific you again) call to make/.