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.

[jacob navia]

bernard wrote:

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.

Hi bernard:

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

Compiler has extensive math library. Language accepted is C99.

Price: Zero dollar and zero cents, for personal use.

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

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

[Keith Thompson]

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

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

Compiler has extensive math library. Language accepted is C99.

Nearly.

Price: Zero dollar and zero cents, for personal use.

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

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

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.

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

[fb]

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.

That was a good compiler...but I thought it was DOS only and the
development seems to have gone slightly stale. Still...an excellent
compiler from what I recall.

[Richard Heathfield]

bernard said:

howdy!

please recommend a good c compiler.

http://www.cpax.org.uk/prg/portable/...#FreeCompilers

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

[s0suk3]

On Sep 24, 12:02*am, Richard Heathfield <rj*@see.sig.invalidwrote:

bernard said:

howdy!

please recommend a good c compiler.

http://www.cpax.org.uk/prg/portable/...#FreeCompilers

Is the 'lcc' compiler listed below the 'The Digital Mars C compiler'
the same as Jacob's lcc-win?

Sebastian

[Richard Heathfield]

s0****@gmail.com said:

On Sep 24, 12:02 am, Richard Heathfield <rj*@see.sig.invalidwrote:

>bernard said:

howdy!

please recommend a good c compiler.

http://www.cpax.org.uk/prg/portable/...#FreeCompilers

Is the 'lcc' compiler listed below the 'The Digital Mars C compiler'
the same as Jacob's lcc-win?

As I understand it, Jacob Navia took the lcc source code and used it as the
basis for lcc-win32. So the answer to your question is really "it was,
once, but is no longer".

The lcc-win32 compiler /used/ to be on the list, but I took it off when I
realised that the maintainer wasn't particularly concerned about
conformance (a position that he has made abundantly clear on many
occasions by his impatience towards reports of conformance errors in his
compiler). It's a list of C compilers, not a list of "ain't my language
cute and by the way doesn't it look a bit like C?" compilers.

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

[s0suk3]

On Sep 24, 12:39*am, Richard Heathfield <rj*@see.sig.invalidwrote:

s0****@gmail.com said:

On Sep 24, 12:02 am, Richard Heathfield <rj*@see.sig.invalidwrote:

bernard said:

howdy!

please recommend a good c compiler.

>http://www.cpax.org.uk/prg/portable/...#FreeCompilers

Is the 'lcc' compiler listed below the 'The Digital Mars C compiler'
the same as Jacob's lcc-win?

As I understand it, Jacob Navia took the lcc source code and used it as the
basis for lcc-win32. So the answer to your question is really "it was,
once, but is no longer".

The lcc-win32 compiler /used/ to be on the list, but I took it off when I
realised that the maintainer wasn't particularly concerned about
conformance (a position that he has made abundantly clear on many
occasions by his impatience towards reports of conformance errors in his
compiler). It's a list of C compilers, not a list of "ain't my language
cute and by the way doesn't it look a bit like C?" compilers.

I see you still hold the absurd position that a non-fully-conforming
compiler "isn't a C compiler"... Well well, no need to discuss that
all over again!

Sebastian

[Richard Heathfield]

s0****@gmail.com said:

<snip>

>
I see you still hold the absurd position that a non-fully-conforming
compiler "isn't a C compiler"...

I see you still hold the absurd position that C compilers are not obliged
to implement the C language correctly. I don't see how this view excludes,
say, the GFA BASIC compiler from being a C compiler. In fact, I don't see
how it excludes a garden fork or a cup of coffee from being a C compiler.

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

[s0suk3]

On Sep 24, 1:07*am, Richard Heathfield <rj*@see.sig.invalidwrote:

s0****@gmail.com said:

<snip>

I see you still hold the absurd position that a non-fully-conforming
compiler "isn't a C compiler"...

I see you still hold the absurd position that C compilers are not obliged
to implement the C language correctly.

Where did I say that C compilers are not obliged to implement the C
language correctly?

I don't see how this view excludes,
say, the GFA BASIC compiler from being a C compiler. In fact, I don't see
how it excludes a garden fork or a cup of coffee from being a C compiler.

This excludes them: common sense. (Although you don't make very heavy
use of that.)

Sebastian

[Richard Heathfield]

s0****@gmail.com said:

On Sep 24, 1:07 am, Richard Heathfield <rj*@see.sig.invalidwrote:

>s0****@gmail.com said:

<snip>

I see you still hold the absurd position that a non-fully-conforming
compiler "isn't a C compiler"...

I see you still hold the absurd position that C compilers are not
obliged to implement the C language correctly.

Where did I say that C compilers are not obliged to implement the C
language correctly?

If you agree that C compilers *are* obliged to implement the C language
correctly, you share my "absurd" position that a non-fully-conforming
compiler isn't a C compiler.

>I don't see how this view excludes,
say, the GFA BASIC compiler from being a C compiler. In fact, I don't
see how it excludes a garden fork or a cup of coffee from being a C
compiler.

This excludes them: common sense.

Yes, but common sense also excludes (from the set of all C compilers)
compilers that don't implement C, and yet until your most recent
disclaimer (quoted above - "Where did I say that C compilers are not
obliged...") it did seem that you wanted to include compilers that don't
implement C, which flies in the face of common sense.

(Although you don't make very heavy use of that.)

That may or may not be true, but you haven't demonstrated it to be true.

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

[s0suk3]

On Sep 24, 1:34*am, Richard Heathfield <rj*@see.sig.invalidwrote:

s0****@gmail.com said:

On Sep 24, 1:07 am, Richard Heathfield <rj*@see.sig.invalidwrote:

s0****@gmail.com said:

<snip>

I see you still hold the absurd position that a non-fully-conforming
compiler "isn't a C compiler"...

I see you still hold the absurd position that C compilers are not
obliged to implement the C language correctly.

Where did I say that C compilers are not obliged to implement the C
language correctly?

If you agree that C compilers *are* obliged to implement the C language
correctly, you share my "absurd" position that a non-fully-conforming
compiler isn't a C compiler.

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". In any event,
there are still more important things in an implementation than full
conformance, such as actual usability, as I've mentioned before (e.g.,
powerful libraries, good optimization, innovative language extensions,
etc).

I don't see how this view excludes,
say, the GFA BASIC compiler from being a C compiler. In fact, I don't
see how it excludes a garden fork or a cup of coffee from being a C
compiler.

This excludes them: common sense.

Yes, but common sense also excludes (from the set of all C compilers)
compilers that don't implement C, and yet until your most recent
disclaimer (quoted above - "Where did I say that C compilers are not
obliged...") it did seem that you wanted to include compilers that don't
implement C, which flies in the face of common sense.

Terminology disagreements. Let's forget them.

Sebastian

[Richard Heathfield]

s0****@gmail.com said:

On Sep 24, 1:34 am, Richard Heathfield <rj*@see.sig.invalidwrote:

>s0****@gmail.com said:

On Sep 24, 1:07 am, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@gmail.com said:

><snip>

I see you still hold the absurd position that a
non-fully-conforming compiler "isn't a C compiler"...

>I see you still hold the absurd position that C compilers are not
obliged to implement the C language correctly.

Where did I say that C compilers are not obliged to implement the C
language correctly?

If you agree that C compilers *are* obliged to implement the C language
correctly, you share my "absurd" position that a non-fully-conforming
compiler isn't a C compiler.

No, because fully-conforming is not the same as correctly.

If an implementation does not translate C programs according to the C
language definition, how can it be considered a C implementation?

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

The incorrectness is in the program, not the implementation. But you merely
place an *additional* constraint on C implementations, the constraint of
"reasonableness", the constraint of "not deliberately setting out to wreak
revenge on the hapless programmer" - and of course mainstream
implementations do observe this constraint. Nevertheless, programmers
would do well to stick to the rules of C if they wish their code to work.

In any event,
there are still more important things in an implementation than full
conformance,

I agree. Nevertheless, without conformance, it isn't a C implementation. It
might be a very important implementation indeed with lots of very
important features but, for it to be a C implementation, I do think it
needs to implement C.

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

[cr88192]

"bernard" <no****@nospam.invalidwrote in message
news:68****************@aioe.org...

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.

MinGW and Cygwin are good.
each has different merits, but I more prefer MinGW for technical reasons
(but Cygwin is better at being a "nicer" framework with a better set of
tools).

free IDE's are also available, but I don't personally use them.

awaiting replies.

[jacob navia]

s0****@gmail.com wrote:

On Sep 24, 12:02 am, Richard Heathfield <rj*@see.sig.invalidwrote:

>bernard said:

>>howdy!
please recommend a good c compiler.

http://www.cpax.org.uk/prg/portable/...#FreeCompilers

Is the 'lcc' compiler listed below the 'The Digital Mars C compiler'
the same as Jacob's lcc-win?

Sebastian

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

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

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

[jacob navia]

Richard Heathfield wrote:

The lcc-win32 compiler /used/ to be on the list, but I took it off when I
realised that the maintainer wasn't particularly concerned about
conformance (a position that he has made abundantly clear on many
occasions by his impatience towards reports of conformance errors in his
compiler).

This is a lie by somebody that has made abundantly clear that
he hates my compiler. I have worked years implementing C99, and I have
now an implementation that is not missing any important feature.

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

[cr88192]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:1M******************************@bt.com...

s0****@gmail.com said:

<snip>

>>
I see you still hold the absurd position that a non-fully-conforming
compiler "isn't a C compiler"...

I see you still hold the absurd position that C compilers are not obliged
to implement the C language correctly. I don't see how this view excludes,
say, the GFA BASIC compiler from being a C compiler. In fact, I don't see
how it excludes a garden fork or a cup of coffee from being a C compiler.

forall A (A or not A)

not a very useful way to think IMO.
if something accepts and compiles C (for the vast majority of inputs), even
if imperfectly in some edge cases, and offers a few extensions, it can still
be classified as a C compiler IMO.

the other things listed, however, will not compile any valid C programs...

it is much the same as if someone goes and declares that someone goes to
hell if they have ever become aroused, and that arousal is of an analogous
level of guilt to adultery (even if the person in question is not married,
the logic can be followed out this way).

this position is absurd (and yes, some people go in this direction in terms
of their doctrine).

so, please refrain from this style of thinking, it is silly...

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

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>The lcc-win32 compiler /used/ to be on the list, but I took it off when
I realised that the maintainer wasn't particularly concerned about
conformance (a position that he has made abundantly clear on many
occasions by his impatience towards reports of conformance errors in his
compiler).

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

You are mistaken on both counts. It's not a lie (you don't appear to know
what the word means), and I don't hate your compiler. I've never even used
your compiler, so how could I hate it?

Now, you clearly disagree with my claim that you aren't particularly
concerned with conformance. But if you *are* concerned about the
conformance issues in your implementation, why haven't you fixed them?

I have worked years implementing C99,

Does it conform yet?

and I have
now an implementation that is not missing any important feature.

Conformance is an important feature.

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

[Richard Heathfield]

cr88192 said:

>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:1M******************************@bt.com...

>s0****@gmail.com said:

<snip>

>>>
I see you still hold the absurd position that a non-fully-conforming
compiler "isn't a C compiler"...

I see you still hold the absurd position that C compilers are not
obliged to implement the C language correctly. I don't see how this view
excludes, say, the GFA BASIC compiler from being a C compiler. In fact,
I don't see how it excludes a garden fork or a cup of coffee from being
a C compiler.

forall A (A or not A)

not a very useful way to think IMO.

Nor is it an accurate reflection of my point.

if something accepts and compiles C (for the vast majority of inputs),
even if imperfectly in some edge cases, and offers a few extensions, it
can still be classified as a C compiler IMO.

Extensions are neither here nor there, since any conforming implementation
is allowed to provide them as long as it doesn't break anything. I'm
tempted to agree about the "imperfectly in some edge cases" provided the
implementation is being actively maintained and that reports of
non-conformance are swiftly acted upon. (This is purely in recognition of
the "last bug" problem - the implementor never quite knows whether his
implementation behaves exactly as planned, because you can't test
infinitely many cases.)

so, please refrain from this style of thinking, it is silly...

The absurd examples I gave were a consequence of his style of thinking, not
mine.

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

[s0suk3]

On Sep 24, 2:01*am, Richard Heathfield <rj*@see.sig.invalidwrote:

s0****@gmail.com said:

On Sep 24, 1:34 am, Richard Heathfield <rj*@see.sig.invalidwrote:

s0****@gmail.com said:

On Sep 24, 1:07 am, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@gmail.com said:

<snip>

I see you still hold the absurd position that a
non-fully-conforming compiler "isn't a C compiler"...

I see you still hold the absurd position that C compilers are not
obliged to implement the C language correctly.

Where did I say that C compilers are not obliged to implement the C
language correctly?

If you agree that C compilers *are* obliged to implement the C language
correctly, you share my "absurd" position that a non-fully-conforming
compiler isn't a C compiler.

No, because fully-conforming is not the same as correctly.

If an implementation does not translate C programs according to the C
language definition, how can it be considered a C implementation?

Perhaps it does translate programs according to the language
definition, but it lacks a set of features. Perhaps it adds a set of
features. Perhaps it imposes modifications on a set of features. This
sort of things are common among C implementations, and that doesn't
prevent them from being C implementations.

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

The incorrectness is in the program, not the implementation.

Sure, the program incorrectly dereferences a pointer that it
shouldn't. But I was talking about the compiler executing that command
under that circumstance. Thankfully, I can now see your notion of
"correctness".

But you merely
place an *additional* constraint on C implementations, the constraint of
"reasonableness", the constraint of "not deliberately setting out to wreak
revenge on the hapless programmer"

Hapless? I thought you had agreed that even the most experienced
programmer will make this sort of mistake.

- and of course mainstream
implementations do observe this constraint. Nevertheless, programmers
would do well to stick to the rules of C if they wish their code to work.

<snip>

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

Sebastian

[Nick Keighley]

On 23 Sep, 23:33, bernard <[e-mail]:

howdy!

yo

please recommend a good c compiler.

- should be small

why? This is a serious question. Modern hardware comes
with vast resources for low prices. Are you running
your compiler on a toaster or something?

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

i am using windows os.

Microsoft provide a free version of their compiler.
Look for "express"

awaiting replies.

I'm not sure what that means
--
Nick Keighley

[s0suk3]

On Sep 24, 2:06*am, "cr88192" <cr*****@NOSPAM.hotmail.comwrote:

"Richard Heathfield" <rj*@see.sig.invalidwrote in message

news:1M******************************@bt.com...

s0****@gmail.com said:

<snip>

I see you still hold the absurd position that a non-fully-conforming
compiler "isn't a C compiler"...

I see you still hold the absurd position that C compilers are not obliged
to implement the C language correctly. I don't see how this view excludes,
say, the GFA BASIC compiler from being a C compiler. In fact, I don't see
how it excludes a garden fork or a cup of coffee from being a C compiler.

forall A (A or not A)

not a very useful way to think IMO.

if something accepts and compiles C (for the vast majority of inputs), even
if imperfectly in some edge cases, and offers a few extensions, it can still
be classified as a C compiler IMO.

the other things listed, however, will not compile any valid C programs....

it is much the same as if someone goes and declares that someone goes to
hell if they have ever become aroused, and that arousal is of an analogous
level of guilt to adultery (even if the person in question is not married,
the logic can be followed out this way).

this position is absurd (and yes, some people go in this direction in terms
of their doctrine).

so, please refrain from this style of thinking, it is silly...

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

[s0suk3]

(Oops, sorry for my empty previous post.)

On Sep 24, 2:06*am, "cr88192" <cr*****@NOSPAM.hotmail.comwrote:

"Richard Heathfield" <rj*@see.sig.invalidwrote in message

news:1M******************************@bt.com...

s0****@gmail.com said:

<snip>

I see you still hold the absurd position that a non-fully-conforming
compiler "isn't a C compiler"...

I see you still hold the absurd position that C compilers are not obliged
to implement the C language correctly. I don't see how this view excludes,
say, the GFA BASIC compiler from being a C compiler. In fact, I don't see
how it excludes a garden fork or a cup of coffee from being a C compiler.

forall A (A or not A)

not a very useful way to think IMO.

if something accepts and compiles C (for the vast majority of inputs), even
if imperfectly in some edge cases, and offers a few extensions, it can still
be classified as a C compiler IMO.

the other things listed, however, will not compile any valid C programs....

it is much the same as if someone goes and declares that someone goes to
hell if they have ever become aroused, and that arousal is of an analogous
level of guilt to adultery (even if the person in question is not married,
the logic can be followed out this way).

this position is absurd (and yes, some people go in this direction in terms
of their doctrine).

so, please refrain from this style of thinking, it is silly...

Thanks for bringing some common sense into this Dark World Of
Nonsense.

Sebastian

[Nick Keighley]

On 24 Sep, 08:03, jacob navia <[e-mail]:

Richard Heathfield wrote:

The lcc-win32 compiler /used/ to be on the list, but I took it off when I
realised that the maintainer wasn't particularly concerned about
conformance (a position that he has made abundantly clear on many
occasions by his impatience towards reports of conformance errors in his
compiler).

This is a lie by somebody that has made abundantly clear that
he hates my compiler. I have worked years implementing C99, and I have
now an implementation that is not missing any important feature.

good grief.

I was just about to suggest to Richard that he add lcc-win
back onto the list of free compilers as near compliance as
opposed to full compliance is good enough. Perhaps with a
caveat that it is only free for non-commercial use (this
isn't a criticism) and that it has a few compliance holes
(but then all real-world compilers probably do). But your
post kind of illustrates your attitude to compliance.
--
Nick Keighley

[Chris Dollin]

s0****@gmail.com wrote:

Terminology disagreements. Let's forget them.

If we forget them
Then our languages will confuse
One and another.

Let us remember our disagreements
But without making them
occasions of turbulence.

[Turbulence
is off-topic
in comp.lang.c.]

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Bartc]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Hu******************************@bt.com...

s0****@gmail.com said:

>Is the 'lcc' compiler listed below the 'The Digital Mars C compiler'
the same as Jacob's lcc-win?

As I understand it, Jacob Navia took the lcc source code and used it as
the
basis for lcc-win32. So the answer to your question is really "it was,
once, but is no longer".

The lcc-win32 compiler /used/ to be on the list, but I took it off when I
realised that the maintainer wasn't particularly concerned about
conformance (a position that he has made abundantly clear on many
occasions by his impatience towards reports of conformance errors in his
compiler). It's a list of C compilers, not a list of "ain't my language
cute and by the way doesn't it look a bit like C?" compilers.

I use lcc-win32 for compiling code appearing on c.l.c. In that regard, it
performs quite adequately. So I would call it a C compiler.

I also use Mingw and DMC for second opinions. I once used Pelles C too but I
can't get that working again.

I've also just looked at lcc on your list, but since it seems to be
distributed as source code, I couldn't actually run it (lcc42.zip). So
lcc-win32 is much more use here than lcc, for someone running Windows.

--
Bartc

[jacob navia]

s0****@gmail.com wrote:

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

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

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

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

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

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

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

[Richard Heathfield]

s0****@gmail.com said:

On Sep 24, 2:01 am, Richard Heathfield <rj*@see.sig.invalidwrote:

<snip>

>>
If an implementation does not translate C programs according to the C
language definition, how can it be considered a C implementation?

Perhaps it does translate programs according to the language
definition, but it lacks a set of features.

If the features are required for conformance, then it is only translating
programs according to a subset of the language definition.

Perhaps it adds a set of features.

That's fine, as long as the extensions don't break strictly conforming
programs.

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

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

The incorrectness is in the program, not the implementation.

Sure, the program incorrectly dereferences a pointer that it
shouldn't. But I was talking about the compiler executing that command
under that circumstance.

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

Thankfully, I can now see your notion of "correctness".

I doubt it.

>

>But you merely
place an *additional* constraint on C implementations, the constraint of
"reasonableness", the constraint of "not deliberately setting out to
wreak revenge on the hapless programmer"

Hapless? I thought you had agreed that even the most experienced
programmer will make this sort of mistake.

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

>- and of course mainstream
implementations do observe this constraint. Nevertheless, programmers
would do well to stick to the rules of C if they wish their code to
work.

<snip>

The point is that the word "conformance" is very meaningless in the
context of C,

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

unless you add that magical ingredient: common sense.

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

Without it, a conforming implementation is some sort of program that
can blow up your machine or make demons fly out of your nose.

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

And when
you do take common sense into account, you'll realize that what
*really* is important in a C implementation, which you don't seem to
see now, and which isn't full conformance.

Full conformance is important to people who need to be able to move their C
programs between one implementation and another. It seems clear to me that
you are not one such person. If that is so, it is not surprising that you
are not particularly fussed about conformance. Nevertheless, there are
people who *rely* on the conformance of compilers to the Standard, because
their programs are *required* to be portable. And there are more such
people than you appear to realise.

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

[Richard Heathfield]

jacob navia said:

<snip>

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

Wrong. Extensions that don't break any strictly conforming program do not
compromise conformance.

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

It is useless to criticise me for holding positions that I don't actually
hold.

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

[James Kuyper]

jacob navia wrote:
....

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

o C89: no long long, nor long double.

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

[jacob navia]

James Kuyper wrote:

jacob navia wrote:
...

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

o C89: no long long, nor long double.

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

long double declarations are recognized and silently ignored.

The resulting code is the same as double

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

[Chris Dollin]

jacob navia wrote:

long double declarations are recognized and silently ignored.

The resulting code is the same as double

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

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[James Kuyper]

jacob navia wrote:

James Kuyper wrote:

>jacob navia wrote:
...

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

o C89: no long long, nor long double.

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

long double declarations are recognized and silently ignored.

The resulting code is the same as double

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

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

A diagnostic is required. Does lcc produce that diagnostic?

[jacob navia]

Chris Dollin wrote:

jacob navia wrote:

>long double declarations are recognized and silently ignored.

The resulting code is the same as double

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

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

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

[jacob navia]

James Kuyper wrote:

jacob navia wrote:

>James Kuyper wrote:

>>jacob navia wrote:
...
No. That is the original lcc, without the work I have done:

o C89: no long long, nor long double.

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

long double declarations are recognized and silently ignored.

The resulting code is the same as double

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

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

>
A diagnostic is required. Does lcc produce that diagnostic?

Yes

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

[CBFalconer]

jacob navia wrote:

s0****@gmail.com wrote:

.... snip ...

>

>Is the 'lcc' compiler listed below the 'The Digital Mars C
compiler' the same as Jacob's lcc-win?

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

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

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

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

[Bart van Ingen Schenau]

On 24 sep, 14:54, jacob navia <[e-mail]:

James Kuyper wrote:

jacob navia wrote:

The resulting code is the same as double

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

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

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

--
jacob navia

Bart v Ingen Schenau

[user1]

bernard wrote:

howdy!

please recommend a good c compiler.

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

i am using windows os.

awaiting replies.

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

[jameskuyper]

jacob navia wrote:

James Kuyper wrote:

jacob navia wrote:

James Kuyper wrote:
jacob navia wrote:
...
No. That is the original lcc, without the work I have done:

o C89: no long long, nor long double.

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

long double declarations are recognized and silently ignored.

The resulting code is the same as double

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

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

....

A diagnostic is required. Does lcc produce that diagnostic?

Yes

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

[jacob navia]

Bart van Ingen Schenau wrote:

On 24 sep, 14:54, jacob navia <[e-mail]:

>James Kuyper wrote:

>>jacob navia wrote:
The resulting code is the same as double
It is permitted for 'long double' and 'double' to have the same exact
size, alignment requirements, and representation.

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

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

>--
jacob navia

Bart v Ingen Schenau

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

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

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

Obviously for many people here, what matters is not quality but legalese
and they will tell everyone that quality is just unimportant. A compiler
that has no assembler/linker/debugger/Ide etc is prefered to one that
has one since their obscure ideological reasons force them to behave
like jerks. CBFalconer for instance will still complain that
lcc-win doesn't run in a 486. Heathfield will still spit nonsense
when my compiler makes a perfectly C99 compatible extension but
will not complain about other compilers modifying syntax to implement
design by contract. As long as it is NOT lcc-win everything is
accepted.

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

[Keith Thompson]

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

James Kuyper wrote:

>jacob navia wrote:
...

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

o C89: no long long, nor long double.

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

long double declarations are recognized and silently ignored.

The resulting code is the same as double

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

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

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

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

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

--
Keith Thompson (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"

[Keith Thompson]

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

Richard Heathfield wrote:

>The lcc-win32 compiler /used/ to be on the list, but I took it off
when I realised that the maintainer wasn't particularly concerned
about conformance (a position that he has made abundantly clear on
many occasions by his impatience towards reports of conformance
errors in his compiler).

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

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

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

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

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

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

Obviously for many people here, what matters is not quality but legalese

Which people?

and they will tell everyone that quality is just unimportant.

Who?

A compiler
that has no assembler/linker/debugger/Ide etc is prefered to one that
has one

Not at all. Compiler preferences are irrelevant here. This newsgroup
discusses C, not implementations. You have been told this many times
before.

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.

Heathfield will still spit nonsense
when my compiler makes a perfectly C99 compatible extension

Compilers are *allowed* to provide extensions, as I keep on telling you.
Your trouble is that you can't take yes for an answer.

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.

The issue here is not "is it lcc-win or not?" but "does it conform or not?"

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

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

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

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

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

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

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

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

An implementation that:

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

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

is a conforming implementation.

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

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

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

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

*BUT*

Your statement upthread about lcc:

o C89: no long long, nor long double.

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

Obviously for many people here, what matters is not quality but legalese
and they will tell everyone that quality is just unimportant. A compiler
that has no assembler/linker/debugger/Ide etc is prefered to one that
has one since their obscure ideological reasons force them to behave
like jerks. CBFalconer for instance will still complain that
lcc-win doesn't run in a 486. Heathfield will still spit nonsense
when my compiler makes a perfectly C99 compatible extension but
will not complain about other compilers modifying syntax to implement
design by contract. As long as it is NOT lcc-win everything is
accepted.

Bullshit.

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

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

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

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

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

bernard wrote:

>howdy!

please recommend a good c compiler.

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

i am using windows os.

awaiting replies.

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

Also look at these two pages
http://clc-wiki.net/wiki/C_resources:Compilers
http://clc-wiki.net/wiki/C_resources:IDEs
--
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/

[s0suk3]

On Sep 24, 5:57*am, Richard Heathfield <rj*@see.sig.invalidwrote:

s0****@gmail.com said:

On Sep 24, 2:01 am, Richard Heathfield <rj*@see.sig.invalidwrote:

<snip>

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.

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

The incorrectness is in the program, not the implementation.

Sure, the program incorrectly dereferences a pointer that it
shouldn't. But I was talking about the compiler executing that command
under that circumstance.

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

Thankfully, I can now see your notion of "correctness".

I doubt it.

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

>

But you merely
place an *additional* constraint on C implementations, the constraint of
"reasonableness", the constraint of "not deliberately setting out to
wreak revenge on the hapless programmer"

Hapless? I thought you had agreed that even the most experienced
programmer will make this sort of mistake.

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

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

- and of course mainstream
implementations do observe this constraint. Nevertheless, programmers
would do well to stick to the rules of C if they wish their code to
work.

<snip>

The point is that the word "conformance" is very meaningless in the
context of C,

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

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

unless you add that magical ingredient: common sense.

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

Without it, a conforming implementation is some sort of program that
can blow up your machine or make demons fly out of your nose.

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

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

<snip>

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

Sebastian

[jameskuyper]

Keith Thompson wrote:
....

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

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

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

[Tristan Miller]

Greetings.

In article <gb**********@aioe.org>, jacob navia wrote:

Chris Dollin wrote:

>jacob navia wrote:

>>long double declarations are recognized and silently ignored.

The resulting code is the same as double

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

Yes. Long double is equivalent to double. This is a legally correct
way of ignoring long double

No it isn't. A compiler is free to make long double and double the same
size, but they must still be treated as distinct for the purpose of type
checking.

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

[Tristan Miller]

Greetings.

In article
<55**********************************@j22g2000hsf. googlegroups.com>,
s0****@gmail.com wrote:

On Sep 24, 1:34Â*am, Richard Heathfield <rj*@see.sig.invalidwrote:

>s0****@gmail.com said:

On Sep 24, 1:07 am, Richard Heathfield <rj*@see.sig.invalidwrote:
s0****@gmail.com said:

><snip>

I see you still hold the absurd position that a
non-fully-conforming compiler "isn't a C compiler"...

>I see you still hold the absurd position that C compilers are not
obliged to implement the C language correctly.

Where did I say that C compilers are not obliged to implement the C
language correctly?

If you agree that C compilers *are* obliged to implement the C language
correctly, you share my "absurd" position that a non-fully-conforming
compiler isn't a C compiler.

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

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