good c compiler

[bernard]

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.

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
....

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

ITYM:

>I predict that you will do so, but we (RH & me) will argue legalese,
convincing no one but ourselves that we are right and you are wrong.
We are very good at the legalese stuff and we will keep redefining terms
until things come out the way we want them to (at least in our minds,
if nowhere else).

[jacob navia]

Kenny McCormack wrote:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
...

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

ITYM:

>I predict that you will do so, but we (RH & me) will argue legalese,
convincing no one but ourselves that we are right and you are wrong.
We are very good at the legalese stuff and we will keep redefining terms
until things come out the way we want them to (at least in our minds,
if nowhere else).

legalese is the only thing that counts for them.

They are unable to do anything else.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Mark McIntyre]

ja*********@verizon.net wrote:

I make a different prediction:

And I make another prediction: a thread to which Navia trolls his bile
will turn into the longest-running thread of the week.

How exceptionally tiresome he is.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Tristan Miller]

Greetings.

In article <48***************@yahoo.com>, CBFalconer wrote:

bernard wrote:

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

I recommend getting the DJGPP system and gcc. See delorie.com.

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?

Regards,
Tristan

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= < In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you

[Mark McIntyre]

bernard wrote:

howdy!

please recommend a good c compiler.

- should be small

memory and disk are cheap

- should be fast

cpu is also cheap

- should come with a good ide

Serious comment: learn to programme commandline stuff first, its much
simpler and you won't get discouraged trying to figure out all the
window classes and widget stuff.

- should be inexpensive

is free cheap enough?

i am using windows os.

You could always dual-boot into Linux, and get all the above for free
with your basic install.
Failing that MS, Borland and others give away basic versions of their
compiler for free. Search their websites.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[CBFalconer]

Tristan Miller wrote:

s0****@gmail.com wrote:

.... snip ...

>

>No, because fully-conforming is not the same as correctly.
Remember that dereferencing an uninitialized pointer can cause
a fully- conforming implementation to execute the "rm -rf /"
command. I don't know about you, but I don't consider that
"correctness".

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>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

jacob navia wrote:

Bart van Ingen Schenau wrote:

.... snip ...

>

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

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

Richard Heathfield wrote:

jacob navia said:

.... snip ...

>

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

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Ian Collins]

CBFalconer wrote:

jacob navia wrote:

>Bart van Ingen Schenau wrote:

.... snip ...

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

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.

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?

--
Ian Collins.

[jacob navia]

CBFalconer wrote:

jacob navia wrote:

>Bart van Ingen Schenau wrote:

... snip ...

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

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.

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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Ian Collins]

CBFalconer wrote:

Richard Heathfield wrote:

>jacob navia said:

.... snip ...

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

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.

So?

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

--
Ian Collins.

[CBFalconer]

Keith Thompson wrote:

jacob navia <ja***@nospam.comwrites:

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

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[jameskuyper]

CBFalconer wrote:

Keith Thompson wrote:

jacob navia <ja***@nospam.comwrites:

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

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]

jacob navia <ja***@nospam.comwrites:

CBFalconer wrote:

>jacob navia wrote:

>>Bart van Ingen Schenau wrote:

... snip ...

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

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Tristan Miller wrote:

CBFalconer wrote:

>bernard wrote:

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

I recommend getting the DJGPP system and gcc. See delorie.com.

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

Ian Collins wrote:

CBFalconer wrote:

>jacob navia wrote:

>>Bart van Ingen Schenau wrote:

.... snip ...

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

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.

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?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

jacob navia wrote:

CBFalconer wrote:

.... snip ...

>

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

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Ian Collins]

CBFalconer wrote:

jacob navia wrote:

>CBFalconer wrote:

.... snip ...

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

--
Ian Collins.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Ian Collins wrote:

>CBFalconer wrote:

>>jacob navia wrote:
Bart van Ingen Schenau wrote:

.... snip ...

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?

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.

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?

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Flash Gordon]

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

Ian Collins wrote:

>CBFalconer wrote:

>>jacob navia wrote:
Bart van Ingen Schenau wrote:

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

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?

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
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Nick Keighley]

On 24 Sep, 21:42, [e-mail] wrote:

On Sep 24, 5:57*am, Richard Heathfield <[e-mail]:

[e-mail] said:

On Sep 24, 2:01 am, Richard Heathfield <[e-mail]:

Perhaps it imposes modifications on a set of features.

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

This
sort of things are common among C implementations, and that doesn't
prevent them from being C implementations.

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.

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

<snip>

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.

<snip>

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.

<snip>

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

[Flash Gordon]

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

Tristan Miller wrote:

>CBFalconer wrote:

>>bernard wrote:
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.
I recommend getting the DJGPP system and gcc. See delorie.com.

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.

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.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Richard Bos]

Keith Thompson <ks***@mib.orgwrote:

jacob navia <ja***@nospam.comwrites:

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.

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

Richard

[Richard Heathfield]

jacob navia said:

Kenny McCormack wrote:

>In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
...

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

ITYM:

>>I predict that you will do so, but we (RH & me) will argue legalese,
convincing no one but ourselves that we are right and you are wrong.
We are very good at the legalese stuff and we will keep redefining
terms until things come out the way we want them to (at least in our
minds, if nowhere else).

legalese is the only thing that counts for them.

They are unable to do anything else.

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.
So I guess I won't be troubling the bookies for my winnings. Nevertheless,
your response is utterly expected, utterly pointless, and utterly evasive.

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Flash Gordon <sm**@spam.causeway.comwrites:
[...]

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Nick Keighley said:

On 24 Sep, 21:42, [e-mail] wrote:

>On Sep 24, 5:57 am, Richard Heathfield <[e-mail]:

[e-mail] said:
On Sep 24, 2:01 am, Richard Heathfield <[e-mail]:

Perhaps it imposes modifications on a set of features.

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

This
sort of things are common among C implementations, and that doesn't
prevent them from being C implementations.

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.

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

<snip>

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

<snip>

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

You can still do this if you try hard enough. :-O

>
<snip>

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

Read the thread. This guy isn't playing chess - he's playing "can't think
straight" and playing it really well. Very convincing.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Keith Thompson <ks***@mib.orgwrites:

jacob navia <ja***@nospam.comwrites:

[...]

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson (aka, God's rep here on Earth) <ks***@mib.orgwrote to himself:
....

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

[Flash Gordon]

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

Flash Gordon <sm**@spam.causeway.comwrites:
[...]

>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.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[jameskuyper]

jacob navia wrote:

Kenny McCormack wrote:

In article <ln************@nuthaus.mib.org>,
Keith Thompson (aka, God's rep here on Earth) <ks***@mib.orgwrote to himself:
...

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)

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]

Flash Gordon wrote:

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

>Flash Gordon <sm**@spam.causeway.comwrites:
[...]

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

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Flash Gordon]

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

Flash Gordon wrote:

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

>>Flash Gordon <sm**@spam.causeway.comwrites:
[...]
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.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[jacob navia]

Flash Gordon wrote:

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

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.

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

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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Flash Gordon]

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

Flash Gordon wrote:

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

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.

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

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.

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

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

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

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.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[CBFalconer]

Flash Gordon wrote:

>

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

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Flash Gordon wrote:

>>

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

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

jacob navia said:

<snip>

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

I'm an occasional MSVC user who does use long double sometimes, and I can
attest to the fact that long double is not the same as double under MSVC.
They are treated as different types (in much the same way that int and
long int are treated as different types).

I am well aware that, in later versions of MSVC, the precision of double
and long double are the same. This means that my code that uses long
double doesn't perform quite as impressively under a Microsoft compiler as
it does under other compilers that use a better long double. Nevertheless,
it still works, of course. Sometimes, we accept the fact that
implementations implement a feature poorly, and are simply glad for the
fact that they implement it at all, because otherwise we wouldn't be able
to port our code to them.

nobody will do that.

Really.

<snip>

If you use long double in your interface you can't use MSVC
of course.

Rubbish.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Flash Gordon]

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

jacob navia said:

<snip>

>If you use long double in your interface you can't use MSVC
of course.

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.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[lawrence.jones]

jacob navia <ja***@nospam.comwrote:

>
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?
--
Larry Jones

In a minute, you and I are going to settle this out of doors. -- Calvin

[Ian Collins]

la************@siemens.com wrote:

jacob navia <ja***@nospam.comwrote:

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

Where most != LP64.

--
Ian Collins.

[jacob navia]

la************@siemens.com wrote:

jacob navia <ja***@nospam.comwrote:

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

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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Flash Gordon]

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

la************@siemens.com wrote:

>jacob navia <ja***@nospam.comwrote:

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

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/2...hesnokov/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.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Stephen Sprunk]

la************@siemens.com wrote:

jacob navia <ja***@nospam.comwrote:

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

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

[Antoninus Twink]

On 25 Sep 2008 at 15:32, Richard Heathfield wrote:

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.

[Ian Collins]

jacob navia wrote:

Richard Heathfield wrote:

>>
Let's restore some context, shall we? You said, in message
<gb**********@aioe.org>, "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.

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

--
Ian Collins.

[lawrence.jones]

ja*********@verizon.net wrote:

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

These pictures will remind us of more than we want to remember.
-- Calvin's Mom

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>Richard Heathfield wrote:

>>Let's restore some context, shall we? You said, in message
<gb**********@aioe.org>, "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.

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
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

la************@siemens.com wrote:

ja*********@verizon.net wrote:

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

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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Flash Gordon]

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

Ian Collins wrote:

>jacob navia wrote:

>>Richard Heathfield wrote:
Let's restore some context, shall we? You said, in message
<gb**********@aioe.org>, "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.

Which is different form "perfectly C99 compatible extensions".

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.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Mark L Pappin]

jacob navia <ja***@nospam.comwrites:

Ian Collins wrote:

>jacob navia wrote:

>>Richard Heathfield wrote:
Let's restore some context, shall we? You said, in message
<gb**********@aioe.org>, "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.

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

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