good c compiler

[jacob navia]

The point is that the word "conformance" is very meaningless in the
context of C, unless you add that magical ingredient: common sense.
Without it, a conforming implementation is some sort of program that
can blow up your machine or make demons fly out of your nose. And when
you do take common sense into account, you'll realize that what
*really* is important in a C implementation, which you don't seem to
see now, and which isn't full conformance.

heathfield has no common sense, it is useless to discuss with him.

The Digital Mars C compiler, for instance, that he recommends in
his page features design by contract:

__in {
assert(pre-conditions);
}
__out {
assert(post-conditions)
}

The extensions of Digital Mars are OK, since there isn't even a hint
of a "warning" in that web page. Extensions done by lcc-win however
are BANNED since it is my compiler.

It is useless to ask for common sense to such a person.

 

[Kenny McCormack]

Terminology disagreements (with that ass RH). Let's forget them.

But it is the only thing tha passes for a life for him.
Surely, you don't intend to take that away from him, do you?

 

[James Kuyper]

jacob navia wrote:
....

No. That is the original lcc, without the work I have done:

o C89: no long long, nor long double.

long double was a C89 feature. If you're sure than lcc doesn't support
long double, then it doesn't even conform to C89.

 

[jacob navia]

jacob navia wrote:
...

long double was a C89 feature. If you're sure than lcc doesn't support
long double, then it doesn't even conform to C89.

long double declarations are recognized and silently ignored.

The resulting code is the same as double

 

[Chris Dollin]

long double declarations are recognized and silently ignored.

The resulting code is the same as double

I don't see how those can both be true at once. I think you
mean that the "long" in "long double" declarations is ignored.
Am I right?

 

[James Kuyper]

long double declarations are recognized and silently ignored.

The resulting code is the same as double

It is permitted for 'long double' and 'double' to have the same exact
size, alignment requirements, and representation. However, it is not the
case that they are allowed to be treated as if they were the same type.
As a result, the two declarations below are incompatible:

double func(double);
long double func(long double ld) { return ld++;}

A diagnostic is required. Does lcc produce that diagnostic?

 

[jacob navia]

I don't see how those can both be true at once. I think you
mean that the "long" in "long double" declarations is ignored.
Am I right?

Yes. Long double is equivalent to double. This is a legally correct
way of ignoring long double, as Microsoft does. I implemented long
double in lcc-win and it is a floating type with more precision than
double.

 

[jacob navia]

It is permitted for 'long double' and 'double' to have the same exact
size, alignment requirements, and representation.

Of course, but then... you just do not implement it.

A diagnostic is required. Does lcc produce that diagnostic?

Yes

 

[CBFalconer]

(e-mail address removed) wrote:
.... snip ...


No. That is the original lcc, without the work I have done:

o C89: no long long, nor long double.
o No assembler, you have to use microsoft assembler
o no linker
o no debugger, nor the possibility of a debugger since it
doesn't generate debug information.
o No ide

None of which even slightly affects its viability as a C compiler.
Well, you can argue about the C89 acceptance, but lcc-win32 doesn't
accept C99 code either. gcc at least publishes a complete (modulo
bugs) list of missing C99 features.

 

[Bart van Ingen Schenau]

Of course, but then... you just do not implement it.

Does lcc-win32 use a different size, alignment or representation for
each of the integer types char, short, int, long and long long?
Or have you also not implemented one of those?

Bart v Ingen Schenau

 

[user1]

howdy!

please recommend a good c compiler.

- should be small
- should be fast
- should come with a good ide
- should be inexpensive

i am using windows os.

awaiting replies.

Look over the page at http://www.thefreecountry.com/compilers/cpp.shtml

 

[jameskuyper]

Of course, but then... you just do not implement it. ....

Yes

I asked my question because your earlier wording suggested the
possibility that lcc treats long double as a synonym for double. That
is what I would consider "not implementing it". If lcc does in fact
treat them as distinct but identically-implemented types, I would
describe that as "implementing long double the same way that double is
implemented".

 

[jacob navia]

Does lcc-win32 use a different size, alignment or representation for
each of the integer types char, short, int, long and long long?
Or have you also not implemented one of those?

Bart v Ingen Schenau

I am running in a machine with 32 or 64 bits, and I have to keep
the integer interface as MSVC dictates under windows, and under
linux I have to follow gcc

Since gcc implements long double there is no problem under linux
Under windows there are no floating point arguments to be passed
to the windows API, so I am free to implement things in the best way
possible. Since the machine supports natively long double with a
specific machine type I give access to the user to that as a good
C implementation should do.

Under the power PC architecture I do NOT implement long double since
the machine doesn't support it.

Obviously for many people here, what matters is not quality but legalese
and they will tell everyone that quality is just unimportant. A compiler
that has no assembler/linker/debugger/Ide etc is prefered to one that
has one since their obscure ideological reasons force them to behave
like jerks. CBFalconer for instance will still complain that
lcc-win doesn't run in a 486. 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. As long as it is NOT lcc-win everything is
accepted.

 

[Keith Thompson]

long double declarations are recognized and silently ignored.

The resulting code is the same as double

No, long double declarations are not ignored. lcc, as I understand it
from the discussion in this thread, simply chooses to use the same
representation for long double as for double, while treating them as
distinct types. That is perfectly permissible. If you don't believe
me, check the standard.

In your list above, you imply that lcc's treatment of long long and
long double are equivalent. In fact, as I understand it, it *rejects*
long long and *accepts* (and correctly implements) long double. Do
you see the difference?

I'm guessing that lcc-win makes type char signed by default. Would it
be fair to say that lcc-win doesn't implement signed char, because it
silently ignores the "signed" keyword? If it uses the same
representation for long int as for int, would it be fair to say that
it doesn't implement long int? Of course not.

Sure, it would be nice if lcc implemented long double as a wider type
than double, but that's not a conformance issue.

lcc implements long double in accordance with the C89 standard's
requirements. It is untrue and unfair to claim that it doesn't.

 

[Keith Thompson]

This is a lie by somebody that has made abundantly clear that
he hates my compiler.

"You keep using that word. I do not think it means what you think it
means." -- Inigo Montoya, in The Princess Bride

Please stop throwing that word around. Your use of it is offensive.

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

What unimportant C99 features does lcc-win not yet implement? (No, I
don't trust your judgement about which features are important and
which are not.)

 

[Flash Gordon]

user1 wrote, On 24/09/08 16:05:

Look over the page at http://www.thefreecountry.com/compilers/cpp.shtml

Also look at these two pages
http://clc-wiki.net/wiki/C_resources:Compilers
http://clc-wiki.net/wiki/C_resources:IDEs

 

[Keith Thompson]

I am running in a machine with 32 or 64 bits, and I have to keep
the integer interface as MSVC dictates under windows, and under
linux I have to follow gcc

Since gcc implements long double there is no problem under linux
Under windows there are no floating point arguments to be passed
to the windows API, so I am free to implement things in the best way
possible. Since the machine supports natively long double with a
specific machine type I give access to the user to that as a good
C implementation should do.

Under the power PC architecture I do NOT implement long double since
the machine doesn't support it.

If I didn't know better (and I don't), I'd suspect that you don't know
what "long double" means.

The C standard (both C90 and C99) specifies 3 floating-point types:
float, double, and long double. (The latter can also legally be
referred to as "double long", but I'd consider that poor programming
style.)

It specifies certain minimum requirements for all three types. For
example, FLT_DIG >= 6, DBL_DIG >= 10, LDBL_DIG >= 10. As it happens,
the requirements for long double are exactly the same as the
requirements for double.

An implementation that:

Implements double and meets the standard's requirements for that
type; and

Implements long double as a distinct type with exactly the same
characteristics as double

is a conforming implementation.

For that matter, an implementation for which float happens to meet the
requirements for double can legally use the same characteristics for
*all three* floating-point types.

And on some hardware, it might actually make sense to do so.

Each of C's floating-point types is typically implemented on top of
some specific floating-point format supported by the underlying
hardware (or by software emulation). Note carefully that I'm using
the word "format" rather than "type"; these are not (yet) types in the
C sense.

If a CPU happens to support three different floating-point formats
that meet C's requirements for float, double, and long double (for
example the IEC 60559 single, double, and extended formats), then it
almost certainly makes sense for a C compiler for that CPU to map the
C types float, double, and long double to those formats. And if you
want to criticize the quality of a compiler that fails to do so, as
lcc apparently does, then I won't disagree with you.

*BUT*

Your statement upthread about lcc:

o C89: no long long, nor long double.

was simply misleading. It implies that long double is a new feature
in C99, which it is not. And it implies that lcc doesn't implement
long double, which it most definitely does. It doesn't implement it
in an ideal fashion, and someone considering using lcc should
certainly take that into account.

Obviously for many people here, what matters is not quality but legalese
and they will tell everyone that quality is just unimportant. A compiler
that has no assembler/linker/debugger/Ide etc is prefered to one that
has one since their obscure ideological reasons force them to behave
like jerks. CBFalconer for instance will still complain that
lcc-win doesn't run in a 486. 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. As long as it is NOT lcc-win everything is
accepted.

Bullshit.

You didn't say that the way lcc supports long double is a quality
issue. You implied that it's a conformance issue. If you had
*accurately* described lcc's long double support as a shortcoming but
not a conformance issue, we wouldn't be having this discussion -- or,
if we were, I'd probably be arguing on your side.

I'll just address one of your other points. Name one instance in
which Richard Heathfield has complained about a "perfectly C99
compatible extension" provided by lcc-win.

I predict that you will attempt to do so, that it will turn out either
that Richard wasn't complaining about the extension or that the
extension is not "perfectly C99 compatible", and that you will refuse
to acknowledge this. As always, I hope you prove me wrong.

 

[s0suk3]

(e-mail address removed) said:


If that affects the behaviour of strictly conforming programs, it means the
compiler isn't a C compiler.


Actually, it does (not including extensions which don't break strictly
conforming programs).

Then you'd be contradicting a lot of major vendors who have a strong
position in the evolution of C. But then again, you may choose to use
whatever terminology you wish to; nobody has to take you seriously.

It would not render the implementation non-conforming. It would merely
render it useless except, perhaps, for "education with extreme prejudice"..
Conformance and usefulness are orthogonal. Something need not be a
conforming C implementation to be useful, and a conforming C compiler
might not be useful (for reasons such as we have explored above).
Nevertheless, many conforming C implementations are useful.


I doubt it.

I did when you said that the incorrectness wasn't on the
implementation.

Yes. It seems you don't know what "hapless" means. It means "unlucky" or
"unfortunate". Even the most experienced programmer can be unfortunate
enough to have a lapse of attention.

Yes, but dereferencing an uninitialized pointer isn't bad luck (it
would merely give you a meaningless value or cause a segfault, which
you would notice right away and fix it). It *would* be bad luck, of
course, if the compiler executed "rm -rf /" wiping out even your
entire project -- but never mind, I know you consider this to be
"correct".

On the contrary, the very definition of C has the concept written right
through it. Variants on the word "conform" appear 39 times in my ANSI C
draft, and 54 times in my copy of 9899:1999.

The fact that it appears on the standard doesn't mean it's meaningful.
We'd be back again to "'rm -rf /' under the effect of UB".

Common sense suggests to me that, for an implementation to be considered a
C implementation, it has to follow the rules of C.


Certainly true, insofar as the rules of conformance don't forbid it. So
what?

Obviously that's an exaggerated example; an implementation can't
actually blow up your machine or make demons fly out of your nose. But
it shows how meaningless conformance is by itself, and it shows your
little use of common sense, since you actually took it seriously!

<snip>

Anyway, this is again degenerating into a "Yes!" "No!" "Yes!" "No!"
discussion and I see no point in continuing it only because you're too
stubborn to accept any level of reasonableness.

Sebastian

 

[jameskuyper]

Keith Thompson wrote:
....

I'll just address one of your other points. Name one instance in
which Richard Heathfield has complained about a "perfectly C99
compatible extension" provided by lcc-win.

I predict that you will attempt to do so, that it will turn out either
that Richard wasn't complaining about the extension or that the
extension is not "perfectly C99 compatible", and that you will refuse
to acknowledge this. As always, I hope you prove me wrong.

I make a different prediction: jacob will describe a C99 feature that
is always supported by lcc-win, regardless of command line options,
and never produces diagnostics, even under circumstances where C89
would mandate them. jacob will quote a message where Richard
Heathfield points out that this means that lcc-win has no mode which
fully conforms to C89. jacob considers these features to be legal
"extensions" to C89; as a result, he sees no point in producing the
diagnostics that are mandatory if he wishes to claim conformance to
C89.

 

[Kenny McCormack]

In article <[email protected]>,