good c compiler

[jacob navia]

legalese is the only thing that counts for them.

They are unable to do anything else.

 

[CBFalconer]

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


Hmm... Person A considers this behaviour to be correct, and
Person B considers it to be incorrect. However shall we know
who is right? If only there were some arbiter of correctness
for the C language; some sort of supreme authority to which one
could turn to settle disputes on what is and is not permitted
behaviour for an implementation...

Just to complete your thought (because I have some doubts that some
of the participants in this thread can do so themselves) consider
the position of the the ISO standard for the C language.

Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/> (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf> (C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2> (C99, txt)
<http://www.dinkumware.com/c99.aspx> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>

 

[CBFalconer]

Bart van Ingen Schenau wrote:
.... snip ...


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

FYI gcc is NOT the ISO standard for the C language. Nor is MSVC.

 

[CBFalconer]

jacob navia said:
.... snip ...


Why should it, if it doesn't target a 486? C370 doesn't run on a
486 either, but nobody seems to think that's a problem.

He is repeating his own faults here. He claims (or has claimed)
that lcc-win32 runs under W98. W98 runs on a 486. lcc-win32 does
not.

 

[Ian Collins]

FYI gcc is NOT the ISO standard for the C language. Nor is MSVC.

Don't be an arse, you know what he means. What use is a compiler that
doesn't follow the ABI for its target platform?

 

[jacob navia]

FYI gcc is NOT the ISO standard for the C language. Nor is MSVC.

Excellent Chuck, excellent.

If I am not compatible with gcc under linux I can't make
a system call, I would have to compile all the OS and all the
system libraries before any user could use my compiler.

Under windows the source code isn't even available.
I could not do any call into the windows API. That means
I wouldn't be able to implement any C library and the
compiler would not run.

You, heathfield, thompson and all the others
only care about legalese you see?

I want usable software.

 

[Ian Collins]

He is repeating his own faults here. He claims (or has claimed)
that lcc-win32 runs under W98. W98 runs on a 486. lcc-win32 does
not.

So?

I'm sure there's plenty of win98 apps that don't run on a 486. Not
everyone lives in the past.

 

[CBFalconer]

.... snip from navia ...

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?

If lcc-win32 rejects long long, it doesn't implement C99.

 

[jameskuyper]

If lcc-win32 rejects long long, it doesn't implement C99.

You need to learn to read more carefully. He was talking about lcc,
not lcc-win32. "long long" is one of the features that jacob added to
lcc in the process of creating lcc-win32; he said so in the very same
comment that led to this discussion of long double.

The discussion occurred because the form of his comment implied that
"long long" and "long double" were both not implemented in lcc. We've
since confirmed that he meant that "long long" isn't supported at all
by lcc, while "long double" is implemented by lcc in a perfectly
conforming fashion, as a type with exactly the same characteristics as
"double".

For some reason, jacob confusingly describes that situation by saying
that lcc doesn't implement "long double". Consider a compiler which
implemented two different integer types (such as short/int, int/long,
or long/long long) in exactly the same perfectly conforming way. Most
of the compilers I've ever used implemented both members of one of
those pairs identically. By the same logic, would jacob say that those
compilers did not implement one of the two types? I wouldn't expect
him to do so, but that's the logic he used for "long double".

 

[Keith Thompson]

Excellent Chuck, excellent.

If I am not compatible with gcc under linux I can't make
a system call, I would have to compile all the OS and all the
system libraries before any user could use my compiler.

Under windows the source code isn't even available.
I could not do any call into the windows API. That means
I wouldn't be able to implement any C library and the
compiler would not run.

You, heathfield, thompson and all the others
only care about legalese you see?

I want usable software.

So do I. I also care about conformance to the C standard, at least
for anything that purports to be a C implementation.

Chuck's statement, while perfectly correct on its own, was not
relevant. Of *course* you have to follow the ABI of whatever platform
your compiler targets, as Ian Collins has already said.

On this particular narrow point, I agree with you and I disagree with
Chuck. But because you're mad at me at the moment, you drag my name
into it.

Grow up.

 

[CBFalconer]

IIRC, DJGPP targets MS-DOS. Microsoft Windows can emulate MS-DOS,
but why recommend a compiler for a legacy system which the OP's
OS can emulate rather than one which target's the OP's OS itself?

Because it is quick and accurate. It also operates from the CLI,
so that you can control everything much better (and quicker) that
through some sort of GUI. The installation is really a version of
gcc.

 

[CBFalconer]

Don't be an arse, you know what he means. What use is a compiler
that doesn't follow the ABI for its target platform?

Quite likely it is a compiler that meets all the requirements of
the ISO standard for the C language. What use is a compiler that
fails to do this?

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


Excellent Chuck, excellent.

If I am not compatible with gcc under linux I can't make
a system call, I would have to compile all the OS and all the
system libraries before any user could use my compiler.

Under windows the source code isn't even available.
I could not do any call into the windows API. That means
I wouldn't be able to implement any C library and the
compiler would not run.

You are showing an appalling ignorance. You don't need that source
code to call the API. You don't need that API (in general) to
implement the standard C library.

 

[Ian Collins]

You are showing an appalling ignorance. You don't need that source
code to call the API. You don't need that API (in general) to
implement the standard C library.

The ignorance is yours. If you can build from source, you can impose
your own ABI. The API is not the issue here, the ABI is.

 

[Keith Thompson]

Quite likely it is a compiler that meets all the requirements of
the ISO standard for the C language. What use is a compiler that
fails to do this?

There are plenty of compilers that follow the target API *and* conform
to the C standard (at least the C90 standard). The two are not
mutually exclusive.

 

[Flash Gordon]

CBFalconer wrote, On 25/09/08 05:21:

Quite likely it is a compiler that meets all the requirements of
the ISO standard for the C language. What use is a compiler that
fails to do this?

What makes you think that a compiler that follows the ABI of a platform
cannot *also* fully conform to the C standard? To be perfectly clear,
for the platforms that Jacob has specified (32/64 bit Windows, 32/64 bit
Linux) it is perfectly possible to follow both the platform ABI *and*
the C standard as evidenced by the fact that some compilers *do* this.

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.

Oh, one thing he has got wrong, gcc does not define the ABI for Linux.
Saying it was glibc would be closer, but I suspect it is actually a
Linux steering group (originally just Linus) and not the GNU people.

 

[Flash Gordon]

CBFalconer wrote, On 25/09/08 05:14:

Because it is quick and accurate. It also operates from the CLI,
so that you can control everything much better (and quicker) that
through some sort of GUI. The installation is really a version of
gcc.

MSVC can be used from the command line. The last version of Borland C++
Builder I used could be used from the command line. Both of them can
also build CLI applications. I've not had problems with the speed of
either. Versions of both of them are free. So the only likely problem
with them for the OP is size. They also have several advantages, like
meeting the OPs requirement to have an IDE and also being able to
produce GUI applications (even when building from the command line)
if/when the OP decides to start doing that.

 

[Nick Keighley]

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.

could you give a few examples? That is, of vendor specific features
that break strictly conforming programs?

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

no necessarily. It might not occur until the system is shipped.

Obviously that's an exaggerated example; an implementation can't
actually blow up your machine

there used to be ways to incorrectly program monitors
such that it physically damaged the hardware.

Anyway, this is again degenerating into a "Yes!" "No!" "Yes!" "No!"

yes. I normally drop those. I think its a bit like
the rule in chess. If the same position is repeated three
the game in abandoned and declared a draw.

 

[Richard Bos]

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.

Now, don't be a tease, Keith. It's not nice to ask people to do things
they're incapable of.

Richard

 

[Keith Thompson]

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.