good c compiler

[Keith Thompson]

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.

[snip]
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 was actually hoping you'd prove me wrong by giving a straight
answer, not by refusing to answer the question at all.

You've made a claim. Please back it up.

 

[Kenny McCormack]

I was actually hoping you'd prove me wrong by giving a straight
answer, not by refusing to answer the question at all.

You've made a claim. Please back it up.

Talking to yourself again?

(As they say, the nice thing about talking to yourself is that you
always know what you are going to say)

 

[jacob navia]

Talking to yourself again?

(As they say, the nice thing about talking to yourself is that you
always know what you are going to say)

I made several claims:

(1) That lcc-win has an assembler, a linker, and a debugger, in
contrast to the original lcc that has none. Nobody has denied this
since it would be difficult anyway.
(2) That lcc follows the C89 standard. Nobody discusses that.
(3) That lcc doesn't implement long long. Nobody discussed that.
(4) That lcc doesn't implement long double. This is the same as saying
that MSVC doesn't implement it since it considers long double as
the same length as double. I clarified that lcc does consider long
double as a distinct type but did not implement it in the code
generation.

Nothing, all those wannabe lawyers like thompson and heathfield will
go on and on (helped by Mr kuyper) insulting (McIntyre could not
resist) saying that I am unable to do this or that, laughing around
and telling I say only wrong stuff etc.

Those people are unable to build anything. My compiler system works
and it is used by many people. They have nothing to offer but
legalese, insults, and bad faith.

I implemented long double within lcc-win. And that means implementing
a really different type, i.e. changing the code generation to
accommodate two floating point types that are used with the same
register set, writing the rules, testing the generated code, adding
the library modifications for printf, etc etc.

The implementation of "%Lg" will print a denormalized number correctly
even if it means using a multi-precision package.

That is NOTHING for those people. They will just blindly repeat the only
things they know: legalese legalese and more of that shit.

It is a pity that so many people keep silent when this stuff happens,
maybe because they have succeeded in making all reasonable people
drop this discussion group so that laugh at the expenses of newbees
alone.

TO HELL WITH THEM!

 

[Flash Gordon]

Keith Thompson wrote, On 25/09/08 16:34:

Jacob has, IMHO, made the correct decision in following the platform
ABI for the platforms he is targeting. He just needs to stamp in big
letters across his documentation that on Windows he does not follow it
for "long double" (for perfectly valid reasons) and so people need to
stick to float/double in interfaces which might be accessed from other
implementations.

[...]

Are you sure about that?

My understanding from this thread is that lcc implements long double
with the same size as double, and lcc-win implements long double with
a larger size than double. I haven't seen anything in this thread to
indicate that the latter violates the Windows ABI. But then, I'm not
familiar with the Windows ABI.

If you get a library compiled with lcc-win32 that uses it's long double
how will you pass it a correct value when calling the library from
MSVCC? Same for return values. As to passing pointers to long doubles...

Same problem in reverse if the library is compiled with MSVC and the
header refers to long double, although way round you can fix it by
changing the header.

I've no idea if the ABI defines the format for long double, but using a
different format not supported by a major vendor can lead to problems.

Note that I'm NOT saying Jabob's decision is bad or unreasonable, just
something the users of his compiler need to be aware of IF their code
will be linked with code compiled with other compilers.

 

[Keith Thompson]

I was actually hoping you'd prove me wrong by giving a straight
answer, not by refusing to answer the question at all.

You've made a claim. Please back it up.

[...]

I made several claims:

(1) That lcc-win has an assembler, a linker, and a debugger, in
contrast to the original lcc that has none. Nobody has denied this
since it would be difficult anyway.

A linker, or something like it, is a required part of any C
implementation; it's what implements translation phase 8. I've never
used lcc. I'm guessing that what you mean here is that lcc depends on
some externally provided linker, whereas lcc-win provides its own.
Apparently lcc is just a compiler, whereas lcc-win is a full C
implementation (it includes a runtime library as well, as I recall).
Both aproaches are valid. I have no opinion on which is better; the
lcc approach is fine as long as a working linker is available.

(2) That lcc follows the C89 standard. Nobody discusses that.
(3) That lcc doesn't implement long long. Nobody discussed that.

There wasn't really anything to discuss; as far as I know, the above
claims are all true and uncontroversial.

(4) That lcc doesn't implement long double. This is the same as saying
that MSVC doesn't implement it since it considers long double as
the same length as double. I clarified that lcc does consider long
double as a distinct type but did not implement it in the code
generation.

And there's where you went wrong. lcc, as I understand it, does
implement long double, and your claim that it doesn't is quite simply
factually incorrect. It implements it as a distinct type with the
same characteristics as double, which is specifically permitted by the
standard.

If you want to say that lcc's implementation of long double is of
unacceptably low quality, I won't argue with you. I agree that having
a long double type with greater range and/or precision than double is
A Good Thing. It's just not required by the standard.

DO YOU UNDERSTAND THE DISTINCTION?

I did not insult your precious compiler. I did not criticize your
compiler's implementation of long double. *You* falsely criticized
lcc's implementation of long double, and I called you on it. This
doesn't mean that there are no valid criticisms of lcc's
implementation of long double, merely that your criticism of it was
factually incorrect.

lcc implements long double in a manner that conforms to the C90 and
C99 standards; it satisfies both the letter and the intent of both
standards. What you're actually complaining about, I suspect, is that
lcc doesn't support an extended floating-point format -- but that's
not what you said.

[...]

I implemented long double within lcc-win. And that means implementing
a really different type, i.e. changing the code generation to
accommodate two floating point types that are used with the same
register set, writing the rules, testing the generated code, adding
the library modifications for printf, etc etc.

Implementing long double as a type with wider range and precision than
double is certainly valid. And as a practical matter, I agree
(again!) that it's better than the lcc approach (though the lcc
implementers probably had good reasons for their choice).

The implementation of "%Lg" will print a denormalized number correctly
even if it means using a multi-precision package.

That's great. Seriously.

But the specific claim I asked you to back up was this one:

| 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.

And my subsequent request was:

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

You have yet to provide an example of this.

That is NOTHING for those people. They will just blindly repeat the only
things they know: legalese legalese and more of that shit.

It is a pity that so many people keep silent when this stuff happens,
maybe because they have succeeded in making all reasonable people
drop this discussion group so that laugh at the expenses of newbees
alone.

TO HELL WITH THEM!

Calm down, you're making a fool of yourself.

 

[jameskuyper]

I made several claims:

The claim that Keith was talking about was your claim that "Heathfield
will still spit nonsense when my compiler makes a perfectly C99
compatible extension ...". That isn't on your list; that's the one
he's asking you to back up.

Your first three claims are non-controversial, which is why nobody
discussed them. Your fourth one contains a minor misuse of terminology
which you seem to be unwilling to correct.

(4) That lcc doesn't implement long double. This is the same as saying
that MSVC doesn't implement it since it considers long double as
the same length as double. I clarified that lcc does consider long
double as a distinct type but did not implement it in the code
generation.

Whereas it would have been more accurate to clarify that lcc does
implement it in the code generation, exactly the same way that lcc
implements double in the code generation.

I implemented long double within lcc-win. And that means implementing
a really different type, i.e. changing the code generation to
accommodate two floating point types that are used with the same
register set, writing the rules, testing the generated code, adding
the library modifications for printf, etc etc.

That's useful, and valuable work, and I can appreciate just how hard
it is to do that correctly.

However, it doesn't mean that lcc didn't already implement 'long
double'. Consider someone who took an implementation for which 'int'
and 'short' are identical 16-bit types, and 'long' and 'long long' are
identical 64-bit types. Imagine that he modified it so that 'int' was
now implemented as a 32-bit type, and 'long long' as a 128-bit type.
By your logic, he could say the the original implementation
implemented neither 'int' nor 'long long' - which is nonsense.

 

[jacob navia]

Keith Thompson wrote, On 25/09/08 16:34:

Jacob has, IMHO, made the correct decision in following the platform
ABI for the platforms he is targeting. He just needs to stamp in big
letters across his documentation that on Windows he does not follow it
for "long double" (for perfectly valid reasons) and so people need to
stick to float/double in interfaces which might be accessed from other
implementations.

[...]

Are you sure about that?

My understanding from this thread is that lcc implements long double
with the same size as double, and lcc-win implements long double with
a larger size than double. I haven't seen anything in this thread to
indicate that the latter violates the Windows ABI. But then, I'm not
familiar with the Windows ABI.

If you get a library compiled with lcc-win32 that uses it's long double
how will you pass it a correct value when calling the library from
MSVCC? Same for return values. As to passing pointers to long doubles...

Same problem in reverse if the library is compiled with MSVC and the
header refers to long double, although way round you can fix it by
changing the header.

I've no idea if the ABI defines the format for long double, but using a
different format not supported by a major vendor can lead to problems.

Note that I'm NOT saying Jabob's decision is bad or unreasonable, just
something the users of his compiler need to be aware of IF their code
will be linked with code compiled with other compilers.

No Microsoft header uses long double. The ABI will not mention long
double, so there isn't any problem. If a long double arguments get's
passed to an MSVC library function the prototype is double and NOT long
double since MS never uses long double in their headers. So, there is no
problem, the long double will be passed as a double.

 

[Flash Gordon]

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

Keith Thompson wrote, On 25/09/08 16:34:

[...]
Jacob has, IMHO, made the correct decision in following the platform
ABI for the platforms he is targeting. He just needs to stamp in big
letters across his documentation that on Windows he does not follow it
for "long double" (for perfectly valid reasons) and so people need to
stick to float/double in interfaces which might be accessed from other
implementations.
[...]

Are you sure about that?

My understanding from this thread is that lcc implements long double
with the same size as double, and lcc-win implements long double with
a larger size than double. I haven't seen anything in this thread to
indicate that the latter violates the Windows ABI. But then, I'm not
familiar with the Windows ABI.

If you get a library compiled with lcc-win32 that uses it's long
double how will you pass it a correct value when calling the library
from MSVCC? Same for return values. As to passing pointers to long
doubles...

Same problem in reverse if the library is compiled with MSVC and the
header refers to long double, although way round you can fix it by
changing the header.

I've no idea if the ABI defines the format for long double, but using
a different format not supported by a major vendor can lead to problems.

Note that I'm NOT saying Jabob's decision is bad or unreasonable, just
something the users of his compiler need to be aware of IF their code
will be linked with code compiled with other compilers.

No Microsoft header uses long double.

I said a library built *with* MSVC. Do you know every single library
built using MSVC?

The ABI will not mention long
double, so there isn't any problem.

Please actually read what I wrote. There IS potential for problems.

If a long double arguments get's
passed to an MSVC library function the prototype is double and NOT long
double since MS never uses long double in their headers.

I was not talking about libraries written BY MS, I was talking about
libraries build USING MSVC. Have you looked at the headers for every
single library that is distributed as a binary and built with MSVC?

So, there is no
problem, the long double will be passed as a double.

Not if the header you have never seen specifies long double.

Also you have completely failed to address the converse situation where
someone builds a library using lcc-win32 using long double in the
interface and I then try (without access to the source of the library
since this could be one of your commercial customers) to link to it from
code compiled with MSVC.

As I say, your decision to use higher precision and range for long
double is perfectly defensible but the restrictions it imposed on
linking with code built with different compilers should be clearly stated.

 

[jacob navia]

Please actually read what I wrote. There IS potential for problems.


I was not talking about libraries written BY MS, I was talking about
libraries build USING MSVC. Have you looked at the headers for every
single library that is distributed as a binary and built with MSVC?

MSVC users never use long double since it is the same as double,
nobody will do that. In many headers done with public domain
libraries that build with MSVC I have never seen long double anywhere.

Not if the header you have never seen specifies long double.

Well, it *could* exist. In that case it will give bad results.
And will give identically bad results with gcc. And will give
identical bad results with any other compiler that actually
implements long double.

Also you have completely failed to address the converse situation where
someone builds a library using lcc-win32 using long double in the
interface and I then try (without access to the source of the library
since this could be one of your commercial customers) to link to it from
code compiled with MSVC.

If you use long double in your interface you can't use MSVC
of course. And it is the same with gcc for exactly the same reasons
since gcc implements long double correctly.

As I say, your decision to use higher precision and range for long
double is perfectly defensible but the restrictions it imposed on
linking with code built with different compilers should be clearly stated.

It is clearly stated in the documentation:
Sizes of the basic types, and in the tutorial.

Everywhere long double is specified as 12 bytes under 32 bits,
and 16 bytes under lcc-win/64

In general you can't link statically object code of different
compilers, it just never works. This is but one problem.
The problem of different malloc() systems and usages, the
problem of different calling conventions when returning a structure,
the problem of different long sizes (64 bit gcc "long" is 64 bits,
64 bit lcc "long" is 32 bits) and many other problems like linker
sections with different names, etc.

Libraries work with the compiler you compiled with, unless
you do a DLL.

 

[Flash Gordon]

jacob navia wrote, On 25/09/08 23:06:

MSVC users never use long double since it is the same as double,
nobody will do that. In many headers done with public domain
libraries that build with MSVC I have never seen long double anywhere.

How do you *know* there is no cross-platform library distributed as
source-only which uses long double so as to make the best use of the
platform it is built for and for Windows is built with MSVC? There are
perfectly good reasons for doing this so I would not rule it out.

Well, it *could* exist. In that case it will give bad results.
And will give identically bad results with gcc. And will give
identical bad results with any other compiler that actually
implements long double.

I'll take your word on gcc (vague memories suggest you are correct for
some ports of it, ports that are non-conforming as a result which *is* a
problem). You are correct that any compiler on Windows that makes long
double a different size (having it the same size is *still* an
implementation of long double) will suffer from the same problem.

If you use long double in your interface you can't use MSVC
of course. And it is the same with gcc for exactly the same reasons
since gcc implements long double correctly.

OK, you acknowledge it now. You could have just done that in the first
place.

It is clearly stated in the documentation:
Sizes of the basic types, and in the tutorial.

Does it state that this is incompatible with MSVC? In my opinion it
should. From a strict CLC perspective it does not matter since it
doesn't affect conformance, but it does IMHO matter from a user
perspective. You can even put a possitive spin on it with something like...

"Unlike MS this implementation uses... this gives you higher
precision and greater range but means you must not use long double in an
interface that will be accessed from MSVC and if an interface for a
library specifies long double you will have to edit the relevant header
to change this to double."

Everywhere long double is specified as 12 bytes under 32 bits,
and 16 bytes under lcc-win/64

I'm saying it should explicitly state that this is different to MS.

In general you can't link statically object code of different
compilers, it just never works.

I use dynamic linking myself.

This is but one problem.
The problem of different malloc() systems and usages, the

I've got a library built with MSVC++ which is being called from Delphi,
a different language from a different supplier. A colleague where I used
to work called a library written for MSVC from Borland C++ builder. Of
course, it is easiest when all the compilers use the same library, and
this is one reason why gcc normally uses whatever the "native" C library
happens to be.

problem of different calling conventions when returning a structure,

This *should* be specified by the ABI and all compilers should follow it.

Anyway, the last time we discussed this I pointed you at the
instructions for how to link code from MinGW with code from MSVC.

the problem of different long sizes (64 bit gcc "long" is 64 bits,
64 bit lcc "long" is 32 bits) and many other problems like linker
sections with different names, etc.

If the ABI for Win64 specifies long is 32 bits (which I think likely)
then any native Win64 port of gcc is in my opinion broken if long is not
32 bits. However, I'm not aware of a native Win64 port of gcc.

Libraries work with the compiler you compiled with, unless
you do a DLL.

If you do a DLL using lcc-win32 and the interface uses long double then
you can't call it from MSVC. Note that I specified "library" I did not
specify whether it was dynamically or statically linked because it does
not affect this issue.


I really don't know why you want to make an argument about this when in
my first post on the subject I *stated* there were good reasons for you
choice and also IIRC stated that it is not a conformance issue.

 

[CBFalconer]

.... snip ...

If you get a library compiled with lcc-win32 that uses it's long
double how will you pass it a correct value when calling the
library from MSVCC? Same for return values. As to passing pointers
to long doubles...

Same problem in reverse if the library is compiled with MSVC and
the header refers to long double, although way round you can fix
it by changing the header.

I may be wrong, but I don't ever recall reading an interchange
specification for linkers in any C standard. I.e. I see no reason
to require any of those features.

 

[Keith Thompson]

I may be wrong, but I don't ever recall reading an interchange
specification for linkers in any C standard. I.e. I see no reason
to require any of those features.

No, of course there's no such specification in the C standard.

But seriously, you see no reason for code generated by two different
compilers to be interoperable? If you want to write code that calls
routines provided by the operating system, you don't mind being
required to use exactly the same compiler that was used to compile the
operating system? (Assume that the OS was written in your least
favorite language.)

The C standard doesn't (and shouldn't) require this kind of
interoperability, but other standards and the market do require it.
(Yes, yes, this is all off-topic.)

 

[Flash Gordon]

Richard Heathfield wrote, On 26/09/08 07:57:

jacob navia said:


Rubbish.

I think you missed some of the context. I believe the intent of the
statement was that if you use long double in the interface of a library
compiled with lcc-win32 then you cannot use that pre-compiled library
with MSVC. This is a true statement.

 

[CBFalconer]

.... snip ...


No, of course there's no such specification in the C standard.

But seriously, you see no reason for code generated by two
different compilers to be interoperable? If you want to write
code that calls routines provided by the operating system, you
don't mind being required to use exactly the same compiler that
was used to compile the operating system? (Assume that the OS
was written in your least favorite language.)

Now I didn't say, nor did I mean, that. But expecting two
different linkers to be entirely compatible, without controlling
standards, is a bit much. Nice, but much.

They may even work together, but create different object codes.
For example, changing the order of routines linked.

The lucky thing is that most object code formats have published
open standards, thus encouraging compatible linkers. But not
ensuring.

 

[lawrence.jones]

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

According to your classification of which features are important and
which are not. Other people may well have different opinions. Your
compiler is an impressive piece of work, but I wish you'd stop
pretending that it's complete when you know darned well that it isn't
yet.

 

[lawrence.jones]

MSVC users never use long double since it is the same as double,

And nobody ever uses long since it is the same as int on most platforms,
right?

 

[Ian Collins]

And nobody ever uses long since it is the same as int on most platforms,
right?

Where most != LP64.

 

[jacob navia]

And nobody ever uses long since it is the same as int on most platforms,
right?

And if they would use it, it will not port to lcc-win. As you know, long
double
can be bigger than double.

But can you point me to a header that is supposed to compile
under MSVC that uses long double? There is a lot of public domain
software that compiles under MSVC. Please find one.

MSVC stopped using long double since at least 10 years.

Of course you can throw around ironic remarks like that as
long as you wish, together with your friends. Fact is,
MSVC doesn't even use long double.

 

[Flash Gordon]

jacob navia wrote, On 27/09/08 08:20:

And if they would use it, it will not port to lcc-win. As you know, long
double
can be bigger than double.

My point was about compatibility between compilers on the same platform
and that people need to be aware of where there are incompatibilities.

But can you point me to a header that is supposed to compile
under MSVC that uses long double? There is a lot of public domain
software that compiles under MSVC. Please find one.

It's C++ rather than C, but...
http://www.physionet.org/challenge/2006/sources/yuriy-chesnokov/lib.h

So there is your one example of someone providing a library including
header file using long double. Of course finding such things is hard
because of all the other stuff searches will throw up so I'm not going
to search further.

MSVC stopped using long double since at least 10 years.

Still incorrect. It has long double it just uses the same representation
as double. However, other people are complaining (with justification)
that it does not use a higher precision long double.

Of course you can throw around ironic remarks like that as
long as you wish, together with your friends. Fact is,
MSVC doesn't even use long double.

Still incorrect. It supports long double, it just happens to use the
same representation as double for it.

Anyway, the question was whether other people use long double in
libraries that could be built with MSVC, and I've found one that is.
There are valid reasons for doing this (making best use of the target
platform) and these apply to closed source libraries as well as open
source code.

I still say you have good reason for making long double higher
precision. For all I know unlike with some other compilers you provide
no compatibility with libraries built with MSVC, I just assumed your
users might want to be able to use third-party pre-built libraries,
since I know that I do, and in that case they need to be aware of any
compatibility issues.

Other compiler vendors deliberately make themselves compatible with
MSVC. If you choose not to that is up to you and does not affect your
conformance to the C standard.

 

[Stephen Sprunk]

And nobody ever uses long since it is the same as int on most platforms,
right?

That is, in fact, a significant problem for MSVC and other
Windows-oriented compilers and is why MS had to use the IL32LLP64 model
for its new 64-bit API instead of the more common I32LP64 model.

S