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.

[Richard Heathfield]

s0****@gmail.com said:

On Sep 28, 2:38 pm, Richard Heathfield <rj*@see.sig.invalidwrote:

<snip>

>>
Obviously you feel that I am against the idea of extensions, but I don't
understand why you feel that. If you have some evidence to support your
feeling, why not provide that evidence? If you don't, you can hardly be
surprised if people don't accept that there is any rational basis for
that belief.

(Sebastian)
"For example, lcc-win doesn't conform, but it has the most useful set
of extensions I've ever seen on any compiler."

(Richard Heathfield, in reply to Sebastian)
"If it doesn't implement the language correctly, the extensions are a
moot point."

What has this to do with the point under discussion? Jacob Navia has argued
that I'm against the idea of extensions (and specifically the idea of
extensions in lcc-win32), and what you've quoted says nothing about that
argument - it only says that in a compiler that doesn't implement the
language correctly, the concept of extensions is pretty irrelevant.

Anyway, I don't know why Jacob Navia keeps arguing with you about it.

He doesn't argue. He simply proclaims. If he had an argument, he would be
able to provide evidence to support it.

He should know by now how pointless it is to try to make any sense out
of your words.

<shrugIf my words didn't make any sense, the bright chaps in this group
(Chris Torek, Keith Thompson, Eric Sosman, James Kuyper, etc) would drive
a coach and horses through them. (And yes - sometimes they do.)

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

>jacob navia said:

>>Antoninus Twink wrote:
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?

Exactly.

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.

Arguing against a specific proposed extension is *not* the same as being
opposed either to extensions in general or to lcc-win32 extensions in
particular. Furthermore, arguing against the discussion of proposed
extensions in comp.lang.c is not the same as being opposed either to
extensions in general or to lcc-win32 extensions in particular. Finally,
being opposed to the discussion of *existing* lcc-win32 extensions in this
group is not the same as being opposed either to extensions in general or
to lcc-win32 extensions in particular.

<snip>

>Obviously you feel that I am against the idea of extensions, but I don't
understand why you feel that. If you have some evidence to support your
feeling, why not provide that evidence? If you don't, you can hardly be
surprised if people don't accept that there is any rational basis for
that belief.

Look, the evidence is in Google and in the dozens of discussions that
are archived there. Anyone can read that.

Fine - if there's all this evidence to demonstrate your claim that
"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", you will have no
trouble finding some of that evidence, and posting Message-IDs to show the
world that you're right. The fact that you don't do this suggests strongly
that this evidence doesn't actually exist.

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

s0****@gmail.com wrote:

On Sep 28, 2:38 pm, Richard Heathfield <rj*@see.sig.invalidwrote:

....

>Obviously you feel that I am against the idea of extensions, but I don't
understand why you feel that. If you have some evidence to support your
feeling, why not provide that evidence? If you don't, you can hardly be
surprised if people don't accept that there is any rational basis for that
belief.

(Sebastian)
"For example, lcc-win doesn't conform, but it has the most useful set
of extensions I've ever seen on any compiler."

(Richard Heathfield, in reply to Sebastian)
"If it doesn't implement the language correctly, the extensions are a
moot point."

How does that constitute evidence that he opposes extensions? It's
evidence that he dislikes non-conforming implementations (an eminently
reasonable attitude, IMO), but the topic under discussion is "perfectly
conforming C99 extensions", not non-conforming implementations. Have you
confused those two concepts?

[James Kuyper]

jacob navia wrote:
....

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.

Any extension that has effect while the compiler is in conforming mode
must meet these requirements:

An extension cannot cause behavior inconsistent with that required by
the standard, when the standard imposes restrictions. In particular,
Where the behavior of the code is merely unspecified, and not undefined,
the standard explicitly or implicitly provides two or more possible
behaviors - an extension can change which behavior is chosen, but cannot
cause behavior that is not in the specified range. An extension cannot
suppress diagnostics that the standard defines as mandatory. Finally, an
extension cannot cause a program to be accepted that contains a #error
directive that survives conditional compilation.

Most extensions that do not render a compiler non-conforming are
triggered by the use of a #pragma, or by code constructs that render the
behavior of the program undefined, thereby giving the implementation
almost unlimited permission to do whatever the implementor wants it to
do. In particular, use of identifiers which are reserved to the
implementation is one simple way in which the behavior can become
undefined. There's no reason why such constructs cannot add a keyword,
particularly if the keyword itself is from the namespace reserved to the
implementation.

[bernard]

Keith Thompson wrote:

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.

What does that mean? Is this what Richard Heathfield and s0suk3
are discussing? Does it accept older language only? What does not
work? I am still learning C and still write only text mode standard
C programs. Thanks for all replies.

[Richard Heathfield]

bernard said:

Keith Thompson wrote:

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

What does that mean?

It means that either Jacob Navia's implementation (lcc-win32) has suddenly
achieved C99 conformance and this is his rather strange way of announcing
it, or he's wrong to claim that the "language accepted is C99".

You would be well advised to find a conforming C implementation rather than
risk one that doesn't conform. There are plenty to choose from, and you've
had two good URLs:

http://www.thefreecountry.com/compilers/cpp.shtml

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

I am still learning C and still write only text mode standard
C programs.

Personally, I'd suggest getting yourself at least *two* compilers - gcc
and, perhaps, one of the free Borland offerings - and installing them
both. As you learn C, compile your exercise programs under both compilers.
Learning to keep them both happy will in itself teach you a lot about C!
Specifically, it will help you to distinguish between C itself (which is
what your textbook ought to be teaching you) and the various add-ons that
compiler vendors offer you in the hope of locking your source code into
their product (and yes, sometimes those add-ons are sufficiently valuable
and powerful to get people to opt into such lock-in).

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

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.

But that's not what "long double" *means*.

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

bernard <no****@nospam.invalidwrites:

Keith Thompson wrote:

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

What does that mean? Is this what Richard Heathfield and s0suk3
are discussing? Does it accept older language only? What does not
work? I am still learning C and still write only text mode standard
C programs. Thanks for all replies.

It means simply that lcc-win, to the best of my knowledge, does not
*fully* support the C99 standard. It may or may not support enough of
it for your purposes.

As I recall, some time ago jacob stated that lcc-win did not support
macros that take a variable number of arguments or certain forms of
initializers. He may have implemented these features since then, but
if so I haven't seen (or, to be honest, I may have forgotten) any
indication here or in comp.compilers.lcc.

More recently, jacob has written in this newsgroup:

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

I don't know which features he considers unimportant. You'll have to
decide for yourself whether the remaining unimplemented features are
important to you (which means you'll first have to find out what they
are).

For more specific information about lcc-win, post to
comp.compilers.lcc or contact jacob directly. You should also be
aware that it's free only for non-commercial use (and please don't
rely on my description; read the actual license terms).

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

[James Kuyper]

bernard wrote:

Keith Thompson wrote:

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

What does that mean? Is this what Richard Heathfield and s0suk3
are discussing? Does it accept older language only? What does not
work? I am still learning C and still write only text mode standard
C programs. Thanks for all replies.

It doesn't fully conform to any version of the standard.

In the mode where it comes closest to conforming to C90, it supports as
extensions certain C99 features. In itself, this is not a problem,
conforming implementations are allowed to provide extensions. However,
at least diagnostic message is mandatory under C90 for some uses of most
of those features, and lcc-win does not generate those mandatory
diagnostics. It could be something as simple as "thank you for making
use of this wonderful extension"; the standard says nothing about the
contents of the diagnostic message; but a message of some kind is required.

It also does not fully conform to C99, I don't know the details. jacob
has decided to put a lot of work into certain extensions to C99, at the
expense of failing to completely conform. That's a legitimate business
decision, but it costs him the ability to claim full C99 conformance.

[jacob navia]

James Kuyper wrote:

bernard wrote:

>Keith Thompson wrote:

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

What does that mean? Is this what Richard Heathfield and s0suk3 are
discussing? Does it accept older language only? What does not work? I
am still learning C and still write only text mode standard C
programs. Thanks for all replies.

It doesn't fully conform to any version of the standard.

In the mode where it comes closest to conforming to C90, it supports as
extensions certain C99 features.

For instance, it accepts // comments. Isn't it that HORRIBLE?

In itself, this is not a problem,
conforming implementations are allowed to provide extensions. However,
at least diagnostic message is mandatory under C90 for some uses of most
of those features, and lcc-win does not generate those mandatory
diagnostics.

As I told you, it fails to emit a diagnostic. This is just legalese
that will be corrected as soon as a single customer requires this
legalese.

Until then, the code is correctly generated, and extensions are
accepted.

It could be something as simple as "thank you for making
use of this wonderful extension"; the standard says nothing about the
contents of the diagnostic message; but a message of some kind is required.

Well, no message. And to tell you the truth, I think nobody cares,
excepting language lawyers.

It also does not fully conform to C99, I don't know the details. jacob
has decided to put a lot of work into certain extensions to C99, at the
expense of failing to completely conform.

I have worked for years in this project, and C99 is supported with all
important features there. There may be a few things not done yet, but
they are relatively obscure. The only significant feature missing is
variable arguments in the preprocessor.

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

[Nick Keighley]

On 23 Sep, 23:43, jacob navia <[e-mail]:

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

I got an error when I tried to access the link.
I don't think its there anymore...

--
Nick Keighley

[Chris Dollin]

jacob navia wrote:

James Kuyper wrote:

>bernard wrote:

>>Keith Thompson wrote:

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.

What does that mean? Is this what Richard Heathfield and s0suk3 are
discussing? Does it accept older language only? What does not work? I
am still learning C and still write only text mode standard C
programs. Thanks for all replies.

It doesn't fully conform to any version of the standard.

In the mode where it comes closest to conforming to C90, it supports as
extensions certain C99 features.

For instance, it accepts // comments. Isn't it that HORRIBLE?

Yes, if you want C90 conformance. I don't see the problem: if I
want C90 conformance, I don't want // comments. Berate me all you
(non-specific you) wish for my premisitical desire for C90 conformance,
for /that is not your (non-specific you again) call to make/.

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

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

[Nick Keighley]

On 23 Sep, 23:43, jacob navia <[e-mail]:

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

ah! this link is wrong

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

*this* link is ok
--
Nick Keighley

[Richard Heathfield]

jacob navia said:

James Kuyper wrote:

>bernard wrote:

>>Keith Thompson wrote:

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.

What does that mean? Is this what Richard Heathfield and s0suk3 are
discussing? Does it accept older language only? What does not work? I
am still learning C and still write only text mode standard C
programs. Thanks for all replies.

It doesn't fully conform to any version of the standard.

In the mode where it comes closest to conforming to C90, it supports as
extensions certain C99 features.

For instance, it accepts // comments. Isn't it that HORRIBLE?

This isn't about aesthetics, but about conformance. A C90 implementation is
permitted to accept // comments (just as it is permitted to accept almost
anything) *provided* it issues the required diagnostic message. If it
doesn't issue that message, it isn't C90-conforming.

<snip>

As I told you, it fails to emit a diagnostic. This is just legalese
that will be corrected as soon as a single customer requires this
legalese.

I take it, then, that you accept that lcc-win32 does not conform to any ISO
C Standard, and is therefore not really a C compiler.

Well, no message. And to tell you the truth, I think nobody cares,
excepting language lawyers.

Clearly *you* don't care that lcc-win32 is not a conforming C90
implementation. And you're probably right that nobody else cares either.
But see below.

>It also does not fully conform to C99, I don't know the details. jacob
has decided to put a lot of work into certain extensions to C99, at the
expense of failing to completely conform.

I have worked for years in this project, and C99 is supported with all
important features there. There may be a few things not done yet,

Either it conforms or it doesn't. You say it doesn't. Therefore, it's not a
C99 compiler. And it's not a C90 compiler either, by your own admission.
So it's not a C compiler at all!

Note that the discussion of particular C implementations doesn't really
fall within the purview of this group, so it's hard to see how discussions
of *non*-C implementations can be relevant here.

but
they are relatively obscure. The only significant feature missing is
variable arguments in the preprocessor.

When/if lcc-win32 ever becomes a conforming C99 implementation, that will
be news that many comp.lang.c subscribers will wish to hear. But the
existence of non-conforming non-C compilers isn't news.

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

[Kenny McCormack]

In article <gb**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
....

>It could be something as simple as "thank you for making
use of this wonderful extension"; the standard says nothing about the
contents of the diagnostic message; but a message of some kind is required.

Well, no message. And to tell you the truth, I think nobody cares,
excepting language lawyers.

It *does* emit a diagnostic. The diagnostic is a string of zero length.
According carping kuyper, this is OK.

>It also does not fully conform to C99, I don't know the details. jacob
has decided to put a lot of work into certain extensions to C99, at the
expense of failing to completely conform.

I have worked for years in this project, and C99 is supported with all
important features there. There may be a few things not done yet, but
they are relatively obscure. The only significant feature missing is
variable arguments in the preprocessor.

You could probably get everybody here to shut up if you just said "It
supports most of C99". You could probably also get them STFU
permanently it you said something to the effect of "I don't really care
about conformance - not in the dogmatically religious fundamentalist
Christian way that the regs of CLC do. I care about performance and
usability. I honestly believe that usability is more important than
religious 'conformance'. And I thank God that I don't live in the 14th
Century!"

The problem is that every time this comes up, the scenario goes like this:

newbie: I'm looking for a C compiler for Windows. What do you suggest?
Jacob: You should try my lcc-win32 product. <various bits of
text about how good it is, including some kind of statement,
often in somewhat broken English, to the effect that it
supports C99 features>.

Now, at this point, Heathfield (or one of his minions) will figure out a
way to misinterpret what Jacob has posted (Note that as a non-native
speaker of English, Jacob's English isn't perfect and there's always a
way to construe it badly) and to hijack the thread into the BS that we
always see.

And thus we get to where we are.

[Tristan Miller]

Greetings.

In article <OI******************************@bt.com>, Richard Heathfield
wrote:

Personally, I'd suggest getting yourself at least *two* compilers - gcc
and, perhaps, one of the free Borland offerings - and installing them
both. As you learn C, compile your exercise programs under both
compilers. Learning to keep them both happy will in itself teach you a
lot about C! Specifically, it will help you to distinguish between C
itself (which is what your textbook ought to be teaching you) and the
various add-ons that compiler vendors offer you in the hope of locking
your source code into their product (and yes, sometimes those add-ons are
sufficiently valuable and powerful to get people to opt into such
lock-in).

I don't see how or why this is a good idea. What's wrong with simply
choosing one conforming compiler and making sure to invoke it in
standards-compliant mode? Simply running gcc with
the -Wall -pedantic -ansi options should help the poster distinguish
between C and any implementation-specific extensions, and he won't have to
waste effort of installing, learning, and maintaining two separate
compiler distributions.

And I think it's a bit of a stretch to imply that the GCC folks try to lock
customers into using their product -- it's free to distribute and even to
modify into a very different product. Unlike vendors of proprietary
systems, they don't stand to benefit much from customer lock-in, except to
the degree that the community at large benefits from wider adoption of
their system.

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

[Keith Thompson]

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

James Kuyper wrote:

>bernard wrote:

>>Keith Thompson wrote:
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.

What does that mean? Is this what Richard Heathfield and s0suk3 are
discussing? Does it accept older language only? What does not work?
I am still learning C and still write only text mode standard C
programs. Thanks for all replies.

It doesn't fully conform to any version of the standard.
In the mode where it comes closest to conforming to C90, it supports
as extensions certain C99 features.

For instance, it accepts // comments. Isn't it that HORRIBLE?

No. It just means that lcc-win isn't a fully conforming C90 compiler.
As I recall, you haven't claimed that it is.

This is not a problem. Why are you trying to make it one?

[...]

>It also does not fully conform to C99, I don't know the
details. jacob has decided to put a lot of work into certain
extensions to C99, at the expense of failing to completely conform.

I have worked for years in this project, and C99 is supported with all
important features there. There may be a few things not done yet, but
they are relatively obscure. The only significant feature missing is
variable arguments in the preprocessor.

Apparently all the features that *you* consider important are
supported. And perhaps all the features that any of your customers
consider important are supported. I would think that full C99
conformance might get you more customers, but that's only speculation
on my part; it's a business decision you have to make, and I'm not in
a position to second-guess you.

So, lcc-win supports most, but not all, of C99. It's important for
potential users to understand this, so they can decide for themselves
whether lcc-win will meet their requirements.

But whenever anybody mentions this, you take it as a personal attack.

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

[jameskuyper]

jacob navia wrote:

James Kuyper wrote:

bernard wrote:

Keith Thompson wrote:

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.

What does that mean? Is this what Richard Heathfield and s0suk3 are
discussing? Does it accept older language only? What does not work? I
am still learning C and still write only text mode standard C
programs. Thanks for all replies.

It doesn't fully conform to any version of the standard.

In the mode where it comes closest to conforming to C90, it supports as
extensions certain C99 features.

For instance, it accepts // comments. Isn't it that HORRIBLE?

Don't put words in my mouth. I only said it was non-conforming, not
that it was "HORRIBLE". You clearly don't equate "non-conforming" with
"HORRIBLE", otherwise you'd have put more effort into achieving
conformance before you started adding extensions.

In itself, this is not a problem,
conforming implementations are allowed to provide extensions. However,
at least diagnostic message is mandatory under C90 for some uses of most
of those features, and lcc-win does not generate those mandatory
diagnostics.

As I told you, it fails to emit a diagnostic. This is just legalese
that will be corrected as soon as a single customer requires this
legalese.

Clearly, your customers are not strongly interested in full
conformance to C90; there's no inherent problem with that. You can
choose not to fully conform to C90, there's no problem with that. You
object to the fact that people point out that lcc-win32 does not fully
conform to C90, treating it as an insult; that's where the problem
comes in. If you truly feel that an assertion that "lcc-win32 does not
fully conform to C90" is in fact an insult, your appropriate response
is to fix the non-conformance, so that the "insult" no longer true -
not to lash out at someone for daring to point out this fact.

It could be something as simple as "thank you for making
use of this wonderful extension"; the standard says nothing about the
contents of the diagnostic message; but a message of some kind is required.

Well, no message. And to tell you the truth, I think nobody cares,
excepting language lawyers.

I care. When I work on code that's intended to be portable to other
C90 compilers, I want the compiler to at least warn me when that code
takes advantage of an extension, whether it was inserted accidentally
by me, or deliberately by previous developers. I write code intended
to be so portable, far more often than I write code that deliberately
makes use of implementation-specific extensions.

It also does not fully conform to C99, I don't know the details. jacob
has decided to put a lot of work into certain extensions to C99, at the
expense of failing to completely conform.

I have worked for years in this project, and C99 is supported with all
important features there. There may be a few things not done yet, but
they are relatively obscure. The only significant feature missing is
variable arguments in the preprocessor.

Your definitions of "important", "obscure", and "significant" might
differ from mine; given our previous discussions, I'm certain that
they do. Therefore, in the unlikely event that I was trying to decide
whether or not to make use of your compiler, I'd appreciate a more
detailed and specific list of the ways in which it fails to conform.

[Richard Heathfield]

Tristan Miller said:

Greetings.

In article <OI******************************@bt.com>, Richard Heathfield
wrote:

>Personally, I'd suggest getting yourself at least *two* compilers - gcc
and, perhaps, one of the free Borland offerings - and installing them
both. As you learn C, compile your exercise programs under both
compilers. Learning to keep them both happy will in itself teach you a
lot about C! Specifically, it will help you to distinguish between C
itself (which is what your textbook ought to be teaching you) and the
various add-ons that compiler vendors offer you in the hope of locking
your source code into their product (and yes, sometimes those add-ons
are sufficiently valuable and powerful to get people to opt into such
lock-in).

I don't see how or why this is a good idea.

It's a good idea because it helps you to distinguish between C itself and
the various add-ons that compiler vendors offer you in the hope of locking
your source code into their product.

What's wrong with simply
choosing one conforming compiler and making sure to invoke it in
standards-compliant mode? Simply running gcc with
the -Wall -pedantic -ansi options should help the poster distinguish
between C and any implementation-specific extensions,

me@herecat execs.c
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main(void)
{
int rc = EXIT_SUCCESS;

char * const args[] = { "/bin/ls", NULL };

if(execve(args[0], args, NULL) == -1)
{
perror("execve");
rc = EXIT_FAILURE;
}

puts("We only get here if something went wrong.");

return rc;
}

gcc -W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-ffloat-store -fno-builtin -O2 -g -pg -c -o execs.o execs.c
execs.c: In function `main':
execs.c:9: warning: initialization discards qualifiers from pointer target
type
gcc -W -Wall -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-ffloat-store -fno-builtin -O2 -g -pg -o execs execs.o

(oops @ warning)

No diagnostic message for unistd.h, nor one for exec*(). Implementations
are not required to diagnose extensions that don't break syntax rules or
violate constraints.

And I think it's a bit of a stretch to imply that the GCC folks try to
lock customers into using their product

Since when were the GCC folks a "vendor"?

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

[jameskuyper]

Kenny McCormack wrote:

In article <gb**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
...

It could be something as simple as "thank you for making
use of this wonderful extension"; the standard says nothing about the
contents of the diagnostic message; but a message of some kind is required.

Well, no message. And to tell you the truth, I think nobody cares,
excepting language lawyers.

It *does* emit a diagnostic. The diagnostic is a string of zero length.
According carping kuyper, this is OK.

I had not intended my comment to be misunderstood in that fashion;
though I do see how you could, with malicious intent, twist it that
way. While the standard does not say anything about the actual content
of diagnostic messages, it does say that a diagnostic is a "message
belonging to an implementation-defined subset of the implementation’s
message output". That means that the implementation is required to
provide documentation of how this subset is to be identified. Does lcc-
win come with documentation that allows us to identify a zero-length
output string as a diagnostic message? If so, it would be horrible
QoI, but it would not render the implementation non-conforming. If you
think I've ever said anything to suggest that QoI is irrelevant in
general, you misunderstood me. It's irrelevant to conformance, but
very relevant to users.

....

Christian way that the regs of CLC do. I care about performance and
usability. I honestly believe that usability is more important than
religious 'conformance'.

I think performance and usability are very important, but that an
absolute minimum requirement for a compiler to count as usable is full
conformance. If you can't count on the compiler to what the standard
specifies that it should do, how can it be truly useful for any
purpose other than implementation-specific code? I don't write any
programs where it would be permissible to restrict their portability
to platforms for which lcc-win32 was available?

The problem is that every time this comes up, the scenario goes like this:

newbie: I'm looking for a C compiler for Windows. What do you suggest?
Jacob: You should try my lcc-win32 product. <various bits of
text about how good it is, including some kind of statement,
often in somewhat broken English, to the effect that it
supports C99 features>.

Now, at this point, Heathfield (or one of his minions) will figure out a
way to misinterpret what Jacob has posted (Note that as a non-native
speaker of English, Jacob's English isn't perfect and there's always a
way to construe it badly) and to hijack the thread into the BS that we
always see.

If it were merely a matter of bad English that caused Jacob to promote
a non-conforming implementation of C as a conforming one, the
corrections he's received would have put a stop to that by now. He
honestly doesn't care about the discrepancy between what IS
conformance and what he CALLS conformance, any more than you do.

[Ben Bacarisse]

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

I have worked for years in this project, and C99 is supported with all
important features there. There may be a few things not done yet, but
they are relatively obscure. The only significant feature missing is
variable arguments in the preprocessor.

Do VLA arguments now work? The changes file says nothing that
suggests the issue is resolved but then again maybe the mistake was
mine. When I reported the issue you did not comment so I have no idea
if you even agree that there is a bug with VLAs in lcc-win32.

--
Ben.

[jameskuyper]

Tristan Miller wrote:

Greetings.

In article <OI******************************@bt.com>, Richard Heathfield
wrote:

Personally, I'd suggest getting yourself at least *two* compilers - gcc
and, perhaps, one of the free Borland offerings - and installing them
both. As you learn C, compile your exercise programs under both
compilers. Learning to keep them both happy will in itself teach you a
lot about C! Specifically, it will help you to distinguish between C
itself (which is what your textbook ought to be teaching you) and the
various add-ons that compiler vendors offer you in the hope of locking
your source code into their product (and yes, sometimes those add-ons are
sufficiently valuable and powerful to get people to opt into such
lock-in).

I don't see how or why this is a good idea. What's wrong with simply
choosing one conforming compiler and making sure to invoke it in
standards-compliant mode? Simply running gcc with
the -Wall -pedantic -ansi options should help the poster distinguish
between C and any implementation-specific extensions, and he won't have to
waste effort of installing, learning, and maintaining two separate
compiler distributions.

The problem with that approach a diagnostic is not mandatory for every
implementation-specific feature. Most things that people would
consider to be extensions would cause a failure to compile when using
a compiler that doesn't support the extension. However, most
implementation-specific features are things for which no diagnostic
would be applicable, such as whether or not NULL expands into an
expression with arithmetic type. For instance, consider an
implementation where 'int' and 'long' are the same size. If you write
code that uses memcpy() to copy an array of longs into an array of
ints, there's not many compilers out there which would warn you about
the mismatch. Such code stands an excellent chance of working exactly
as expected on a machine where they are the same size. However, if you
try to compile and do a test run of such code using a compiler where
sizeof(int) < sizeof(long), you stand a very good chance of seeing
something go wrong, which will warn you about the error.

And I think it's a bit of a stretch to imply that the GCC folks try to lock
customers into using their product -- it's free to distribute and even to

I don't think he intended any such implication.

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote in his usual android style,
leading up to:
....

>But whenever anybody mentions this, you take it as a personal attack.

That's because it is always phrased as a personal attack.

Not by you, mind you (*). But by he who shall not be named.

(*) You've actually been reasonably fair in your comments to Jacob,
though I often wonder why you bother. I think we get it by now that
Jacob's compiler is never going to past muster with the "Conformance is
everything! You must conform!" crowd here.

[lawrence.jones]

Mark L Pappin <ml*@acm.orgwrote:

>
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

No, but they certainly *can* appear between two scalar values:

i * *p

You'd have to have a context sensitive lexer to tease apart that
usage (without the whitespace) from your exponentiation operator.
--
Larry Jones

When you're as far ahead of the class as I am, it doesn't take much time.
-- Calvin

[Kenny McCormack]

In article <7b**********************************@k13g2000hse. googlegroups.com>,
<ja*********@verizon.netwrote the usual CLC-influenced crud, leading up to:
....

>Your definitions of "important", "obscure", and "significant" might
differ from mine; given our previous discussions, I'm certain that
they do. Therefore, in the unlikely event that I was trying to decide
whether or not to make use of your compiler, I'd appreciate a more
detailed and specific list of the ways in which it fails to conform.

People who develop for Windows generally don't care that much about
portability. You can argue this or accept it or disagree or whatever,
but it remains true. It is not universally/mathematically true of
course (I'm sure you will find me the counter-example; some guy
somewhere who makes the assertion not universally true).

But the fact remains that Windows developers routinely lock themselves
into the latest flavor-of-the-month from MS; it doesn't seem to bother
them much.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Mon, 29 Sep 2008 13:31:59 -0400, lawrence.jones wrote:

Mark L Pappin <ml*@acm.orgwrote:

>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

No, but they certainly *can* appear between two scalar values:

i * *p

You'd have to have a context sensitive lexer to tease apart that usage
(without the whitespace) from your exponentiation operator.

That's not necessary. All that's needed is to allow binary ** to take an
arithmetic left operand and pointer-to-arithmetic right operand, and to
allow unary ** to take a single operand of type pointer-to-pointer. If
unary and binary ** have the same precedence as unary and binary * (but
there may be other possibilities as well), then current correct instances
of i**p will be accepted.

[Keith Thompson]

Harald van Dijk <tr*****@gmail.comwrites:

On Mon, 29 Sep 2008 13:31:59 -0400, lawrence.jones wrote:

>Mark L Pappin <ml*@acm.orgwrote:

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

No, but they certainly *can* appear between two scalar values:

i * *p

You'd have to have a context sensitive lexer to tease apart that usage
(without the whitespace) from your exponentiation operator.

That's not necessary. All that's needed is to allow binary ** to take an
arithmetic left operand and pointer-to-arithmetic right operand, and to
allow unary ** to take a single operand of type pointer-to-pointer. If
unary and binary ** have the same precedence as unary and binary * (but
there may be other possibilities as well), then current correct instances
of i**p will be accepted.

Ick. Your proposal, or something similar, might work, but I'm not
convinced that there aren't still other cases where it would fail.
For example, if "**" becomes a single token, then you need *another*
special-case rule to avoid breaking declarations like
int **ptr;

And explaining the details to programmers would be difficult:

Teacher: "x ** y" and "x * * y" are two different expressions, but the
operators are carefully defined to make them exactly equivalent.

Student: Huh?

If C needs an exponentiation operator (and I'm not at all convinced it
does), it needs a symbol that doesn't conflict with anything else.
"^^" would do, though there's something to be said for reserving that
for logical exclusive-or (not short-circuiting, obviously).

For that matter, there's no reason an operator can't be a keyword
rather than a symbol (see "sizeof"). The new operator could be _Exp,
with a more user-friendly macro (can't use "exp", that's already a
function) in a new standard header.

*If* something like this were added, it would present an opportunity
to recognize an integral right operand, and use a faster and more
accurate algorithm.

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

jacob navia wrote:

James Kuyper wrote:

>bernard wrote:

.... snip ...

>>

>>What does that mean? Is this what Richard Heathfield and s0suk3
are discussing? Does it accept older language only? What does
not work? I am still learning C and still write only text mode
standard C programs. Thanks for all replies.

It doesn't fully conform to any version of the standard.

In the mode where it comes closest to conforming to C90, it
supports as extensions certain C99 features.

For instance, it accepts // comments. Isn't it that HORRIBLE?

As a matter of fact, YES, if the system is attempting to conform to
C90. The result is that the poor user is never told that his code
is not portable with those successive division symbols.

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

[vippstar]

On Sep 29, 10:41 pm, CBFalconer <[e-mail]:

jacob navia wrote:

James Kuyper wrote:

bernard wrote:

... snip ...

>What does that mean? Is this what Richard Heathfield and s0suk3
are discussing? Does it accept older language only? What does
not work? I am still learning C and still write only text mode
standard C programs. Thanks for all replies.

It doesn't fully conform to any version of the standard.

In the mode where it comes closest to conforming to C90, it
supports as extensions certain C99 features.

For instance, it accepts // comments. Isn't it that HORRIBLE?

As a matter of fact, YES, if the system is attempting to conform to
C90. The result is that the poor user is never told that his code
is not portable with those successive division symbols.

If accepting means to translate without emitting a diagnostic error,
you are correct.
However, the standard seems to use the word 'accept' to talk about the
implementation processing the file.
In that sense, no, it's not horrible as a C90 compiler is *required*
to accept files containing // comments.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Mon, 29 Sep 2008 12:31:58 -0700, Keith Thompson wrote:

Harald van Dijk <tr*****@gmail.comwrites:

>On Mon, 29 Sep 2008 13:31:59 -0400, lawrence.jones wrote:

>>Mark L Pappin <ml*@acm.orgwrote:
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

No, but they certainly *can* appear between two scalar values:

i * *p

You'd have to have a context sensitive lexer to tease apart that usage
(without the whitespace) from your exponentiation operator.

That's not necessary. All that's needed is to allow binary ** to take
an arithmetic left operand and pointer-to-arithmetic right operand, and
to allow unary ** to take a single operand of type pointer-to-pointer.
If unary and binary ** have the same precedence as unary and binary *
(but there may be other possibilities as well), then current correct
instances of i**p will be accepted.

Ick. Your proposal, or something similar, might work, but I'm not
convinced that there aren't still other cases where it would fail. For
example, if "**" becomes a single token, then you need *another*
special-case rule to avoid breaking declarations like
int **ptr;

That's a good point.

And explaining the details to programmers would be difficult:

Teacher: "x ** y" and "x * * y" are two different expressions, but the
operators are carefully defined to make them exactly equivalent.

Student: Huh?

But I'm not so sure about this. As far as the programmer is or should be
concerned, x ** p and x * * p are the same expression. The teacher, if he
is teaching C, shouldn't need to discuss the parser implementation, should
he? How the compiler will accept them as the same expression is what I
believe lawrence jones was talking about, and I as well.

If C needs an exponentiation operator (and I'm not at all convinced it
does), it needs a symbol that doesn't conflict with anything else. "^^"
would do, though there's something to be said for reserving that for
logical exclusive-or (not short-circuiting, obviously).

For that matter, there's no reason an operator can't be a keyword rather
than a symbol (see "sizeof"). The new operator could be _Exp, with a
more user-friendly macro (can't use "exp", that's already a function) in
a new standard header.

How about borrowing from other languages? Allow operators to be used as
functions: +(2, 3) == 2 + 3. Then make pow an operator: pow(2, 3) ==
2 pow 3. (I don't necessarily think this is a good idea; I haven't given
it a lot of thought. I like it at first glance though.)

*If* something like this were added, it would present an opportunity to
recognize an integral right operand, and use a faster and more accurate
algorithm.

That should not have to wait so long. If function overloading is possible,
then pow could be overloaded to accept a second argument of integer type.
And the effect of function overloading is required already for <tgmath.h>;
the interface is merely not standardised.

[Keith Thompson]

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

jacob navia wrote:

[...]

>For instance, it accepts // comments. Isn't it that HORRIBLE?

As a matter of fact, YES, if the system is attempting to conform to
C90. The result is that the poor user is never told that his code
is not portable with those successive division symbols.

If *and only if* the system is attempting to conform to C90.

But jacob has not, as far as I know, ever claimed that lcc-win
conforms to C90. In the absence of such a claim, the fact that it
doesn't diagnose // comments is no worse than the fact that it doesn't
diagnose REM statements.

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

vi******@gmail.com writes:

On Sep 29, 10:41 pm, CBFalconer <[e-mail]:

>jacob navia wrote:

[...]

For instance, it accepts // comments. Isn't it that HORRIBLE?

As a matter of fact, YES, if the system is attempting to conform to
C90. The result is that the poor user is never told that his code
is not portable with those successive division symbols.

If accepting means to translate without emitting a diagnostic error,
you are correct.
However, the standard seems to use the word 'accept' to talk about the
implementation processing the file.
In that sense, no, it's not horrible as a C90 compiler is *required*
to accept files containing // comments.

No, a C90 compiler is not required to accept files containing //, any
more than it's required to accept files containing any other syntax
error. I don't think the standard defines the word "accept", but I
can think of any reasonable meaning that would make your statement
correct.

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

[jameskuyper]

Harald van D©¦k wrote:

On Mon, 29 Sep 2008 13:31:59 -0400, lawrence.jones wrote:

....

No, but they certainly *can* appear between two scalar values:

i * *p

You'd have to have a context sensitive lexer to tease apart that usage
(without the whitespace) from your exponentiation operator.

That's not necessary. All that's needed is to allow binary ** to take an
arithmetic left operand and pointer-to-arithmetic right operand, and to

That's an example of a context-sensitive lexing. Without context, you
can only parse 'i' and 'p' as identifiers. With context, you can
distinguish an identifier which identifies an arithmetic variable from
one which identifies a pointer.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Mon, 29 Sep 2008 13:08:45 -0700, jameskuyper wrote:

Harald van Dijk wrote:

>On Mon, 29 Sep 2008 13:31:59 -0400, lawrence.jones wrote:

...

No, but they certainly *can* appear between two scalar values:

i * *p

You'd have to have a context sensitive lexer to tease apart that
usage (without the whitespace) from your exponentiation operator.

That's not necessary. All that's needed is to allow binary ** to take
an arithmetic left operand and pointer-to-arithmetic right operand, and
to

That's an example of a context-sensitive lexing. Without context, you
can only parse 'i' and 'p' as identifiers. With context, you can
distinguish an identifier which identifies an arithmetic variable from
one which identifies a pointer.

As far as I am aware, the only place where the lexer must look at context
is in the handling of #include directives. In all other cases, including
i**p, the lexer doesn't need any context; it can leave it for the parser
to handle. Once the parser knows i as an identifier, it doesn't need to be
told i is an int, it can figure this out (actually: it has figured this
out) by itself.

[Bartc]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

If C needs an exponentiation operator (and I'm not at all convinced it
does), it needs a symbol that doesn't conflict with anything else.
"^^" would do, though there's something to be said for reserving that
for logical exclusive-or (not short-circuiting, obviously).

Why not just use ^ for exponentiation? For when the left operand is floating
point:

i^j; i xor j
x^n; pow(x,n)

--
Bartc

[Mark L Pappin]

la************@siemens.com writes:

Mark L Pappin <ml*@acm.orgwrote:

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

No, but they certainly *can* appear between two scalar values:

There's a reason I used the word "arithmetic" ...

However, this was not intended as a serious proposal; merely as an
example of an extension that might be possible to shoehorn into a
compiler without breaking any existing code versus one that _does_
cause breakage, since Jacob seems unable to distinguish between them.

mlp

[Keith Thompson]

"Bartc" <[e-mail]:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>If C needs an exponentiation operator (and I'm not at all convinced it
does), it needs a symbol that doesn't conflict with anything else.
"^^" would do, though there's something to be said for reserving that
for logical exclusive-or (not short-circuiting, obviously).

Why not just use ^ for exponentiation? For when the left operand is
floating point:

i^j; i xor j
x^n; pow(x,n)

Because integer exponentiation is also useful. If "^" is just a
synonym for pow(), it doesn't give much value over just calling pow();
the pow() function can already optimize for the case where the right
operand is an exact integer.

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

Mark L Pappin <ml*@acm.orgwrites:

la************@siemens.com writes:

>Mark L Pappin <ml*@acm.orgwrote:

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

No, but they certainly *can* appear between two scalar values:

There's a reason I used the word "arithmetic" ...

However, this was not intended as a serious proposal; merely as an
example of an extension that might be possible to shoehorn into a
compiler without breaking any existing code versus one that _does_
cause breakage, since Jacob seems unable to distinguish between them.

If we're just talking about the legality of a hypothetical
compiler-specific extension, it might be easier to recognize two
consecutive "*" tokens as an exponentiation operator, but only when
there's a syntax error without this interpretation. In addition, you
could issue a warning or error message if a pair of "*" tokens
interpreted as an exponentation operator are separated by whitespace
or a comment (or, of course, if it's used in a context where an
exponentiation operator is invalid). It's not a very clean design,
but it's less likely to break valid code.

This is *not* a serious proposal, just an idle exploration of what's
allowed by the standard.

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

[vippstar]

On Sep 29, 10:50 pm, Harald van D©¦k <[e-mail]:

On Mon, 29 Sep 2008 12:31:58 -0700, Keith Thompson wrote:

If C needs an exponentiation operator (and I'm not at all convinced it
does), it needs a symbol that doesn't conflict with anything else. "^^"
would do, though there's something to be said for reserving that for
logical exclusive-or (not short-circuiting, obviously).

For that matter, there's no reason an operator can't be a keyword rather
than a symbol (see "sizeof"). The new operator could be _Exp, with a
more user-friendly macro (can't use "exp", that's already a function) in
a new standard header.

How about borrowing from other languages? Allow operators to be used as
functions: +(2, 3) == 2 + 3. Then make pow an operator: pow(2, 3) ==
2 pow 3. (I don't necessarily think this is a good idea; I haven't given
it a lot of thought. I like it at first glance though.)

What'd be the type of +?
What would the result of this be:

1 + (2, 3)

In C, as it is defined by ANSI/ISO in the standards, it's 4.

[CBFalconer]

vi******@gmail.com wrote:

CBFalconer <[e-mail]:

>jacob navia wrote:

>>James Kuyper wrote:

.... snip ...

>>

>>>In the mode where it comes closest to conforming to C90, it
supports as extensions certain C99 features.

For instance, it accepts // comments. Isn't it that HORRIBLE?

As a matter of fact, YES, if the system is attempting to conform
to C90. The result is that the poor user is never told that his
code is not portable with those successive division symbols.

If accepting means to translate without emitting a diagnostic
error, you are correct. However, the standard seems to use the
word 'accept' to talk about the implementation processing the
file. In that sense, no, it's not horrible as a C90 compiler is
*required* to accept files containing // comments.

I don't think you meant what you wrote. A C90 compiler is required
to accept the '/' as indicating division. Two in a row are a
syntax error, not a comment, and require a diagnostic.

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

[CBFalconer]

Bartc wrote:

"Keith Thompson" <ks***@mib.orgwrote in message

>If C needs an exponentiation operator (and I'm not at all
convinced it does), it needs a symbol that doesn't conflict
with anything else. "^^" would do, though there's something
to be said for reserving that for logical exclusive-or (not
short-circuiting, obviously).

Why not just use ^ for exponentiation? For when the left operand
is floating point:

i^j; i xor j
x^n; pow(x,n)

Think about parsing:

j = (int)x ^ n;

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

[CBFalconer]

Keith Thompson wrote:

>

.... snip ...

>
If we're just talking about the legality of a hypothetical
compiler-specific extension, it might be easier to recognize two
consecutive "*" tokens as an exponentiation operator, but only
when there's a syntax error without this interpretation. In
addition, you could issue a warning or error message if a pair
of "*" tokens interpreted as an exponentation operator are
separated by whitespace or a comment (or, of course, if it's
used in a context where an exponentiation operator is invalid).
It's not a very clean design, but it's less likely to break
valid code.

I often write:

int foo(char* *p) { ...

just to make clear what the parameter is. To my mind.

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

[lawrence.jones]

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

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

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

Do you think God lets you plea bargain? -- Calvin

[Keith Thompson]

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

Keith Thompson wrote:
... snip ...

>>
If we're just talking about the legality of a hypothetical
compiler-specific extension, it might be easier to recognize two
consecutive "*" tokens as an exponentiation operator, but only
when there's a syntax error without this interpretation. In
addition, you could issue a warning or error message if a pair
of "*" tokens interpreted as an exponentation operator are
separated by whitespace or a comment (or, of course, if it's
used in a context where an exponentiation operator is invalid).
It's not a very clean design, but it's less likely to break
valid code.

I often write:

int foo(char* *p) { ...

just to make clear what the parameter is. To my mind.

Which wouldn't be affected by my suggestion (which, let me emphasize
again, was not a serious one). Either ** or * * would be interpreted
as an exponentation operator only in cases that are currently syntax
errors. Since "int foo(char* *p)" is already valid, it would be
unaffected.

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

[Harald van =?UTF-8?b?RMSzaw==?=]

On Mon, 29 Sep 2008 15:56:09 -0700, vippstar wrote:

On Sep 29, 10:50 pm, Harald van Dijk <[e-mail]:

>On Mon, 29 Sep 2008 12:31:58 -0700, Keith Thompson wrote:

If C needs an exponentiation operator (and I'm not at all convinced
it does), it needs a symbol that doesn't conflict with anything else.
"^^" would do, though there's something to be said for reserving that
for logical exclusive-or (not short-circuiting, obviously).

For that matter, there's no reason an operator can't be a keyword
rather than a symbol (see "sizeof"). The new operator could be _Exp,
with a more user-friendly macro (can't use "exp", that's already a
function) in a new standard header.

How about borrowing from other languages? Allow operators to be used as
functions: +(2, 3) == 2 + 3. Then make pow an operator: pow(2, 3) == 2
pow 3. (I don't necessarily think this is a good idea; I haven't given
it a lot of thought. I like it at first glance though.)

What'd be the type of +?

It wouldn't have a type.

What would the result of this be:

1 + (2, 3)

In C, as it is defined by ANSI/ISO in the standards, it's 4.

It would remain unaffected. Your point is a good one, but the example
should use unary plus: the value of +(2, 3) is currently already defined
as 3, not 5.

[Nick Keighley]

On 29 Sep, 16:34, Tristan Miller <[e-mail]:

In article <[e-mail]>, Richard Heathfield
wrote:

Personally, I'd suggest getting yourself at least *two* compilers - gcc
and, perhaps, one of the free Borland offerings - and installing them
both. As you learn C, compile your exercise programs under both
compilers. Learning to keep them both happy will in itself teach you a
lot about C!

<snip>

I don't see how or why this is a good idea. *What's wrong with simply
choosing one conforming compiler and making sure to invoke it in
standards-compliant mode? *Simply running gcc with
the -Wall -pedantic -ansi options should help the poster distinguish
between C and any implementation-specific extensions, and he won't have to
waste effort of installing, learning, and maintaining two separate
compiler distributions.

in an ideal world a single "perfect" compiler would suffice.
The Perfect Compiler would diagnose all syntax and constraint errors.
It would warn about the use of any extension and even warn about
dubious or potentially error prone constrcuts. Unfortuatly no such
compiler exists 9not even gcc with all those flags) so using a
selection of compilers (and maybe other tools like lint) gets you
closeer
to the Perfect Compiler.

And I think it's a bit of a stretch to imply that the GCC folks try to lock
customers into using their product -- it's free to distribute and even to
modify into a very different product. *Unlike vendors of proprietary
systems, they don't stand to benefit much from customer lock-in, except to
the degree that the community at large benefits from wider adoption of
their system.

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
(Using and Porting GNU CC)

-pedantic
This option is not intended to be useful; it exists only to satisfy
pedants who would otherwise claim that GNU CC fails to support the
ANSI standard.
(Using and Porting GNU CC)

--
Nick Keighley

[Nick Keighley]

On 29 Sep, 19:54, [e-mail] (Kenny McCormack) wrote:

People who develop for Windows generally don't care that much about
portability. *You can argue this or accept it or disagree or whatever,
but it remains true. *It is not universally/mathematically true of
course (I'm sure you will find me the counter-example; some guy
somewhere who makes the assertion not universally true).

But the fact remains that Windows developers routinely lock themselves
into the latest flavor-of-the-month from MS; it doesn't seem to bother
them much.

I sometimes use Windows as a test platform. That is, the final target
is intended to be something else but the code is, partially, tested
under Windows. Windows being a readily available platform. So this
isn't "windows developemnt" per se but does involve using
a Windows hosted platform to develop reasonably portable code. So I
care about extensions.

You see Kenny- you *can* post sensible things!
--
Nick Keighley
The beginning of wisdom for a [software engineer] is to recognize the
difference between getting a program to work, and getting it right.
-- M A Jackson, 1975

[Bartc]

"CBFalconer" <cb********@yahoo.comwrote in message
news:48**************@yahoo.com...

Bartc wrote:

>"Keith Thompson" <ks***@mib.orgwrote in message

>>If C needs an exponentiation operator (and I'm not at all
convinced it does), it needs a symbol that doesn't conflict
with anything else. "^^" would do, though there's something
to be said for reserving that for logical exclusive-or (not
short-circuiting, obviously).

Why not just use ^ for exponentiation? For when the left operand
is floating point:

i^j; i xor j
x^n; pow(x,n)

Think about parsing:

j = (int)x ^ n;

Parsing isn't affected, except that it may be necessary to use a different
name for ^.

When types of operands are considered, then ^ will be split between xor and
pow().

Your example would use xor.

If you mean it's not possible to take the power of an integer value this
way, then yes this is still a limitation.

--
Bartc

[James Kuyper]

Keith Thompson wrote:

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

>jacob navia wrote:

[...]

>>For instance, it accepts // comments. Isn't it that HORRIBLE?

As a matter of fact, YES, if the system is attempting to conform to
C90. The result is that the poor user is never told that his code
is not portable with those successive division symbols.

If *and only if* the system is attempting to conform to C90.

But jacob has not, as far as I know, ever claimed that lcc-win
conforms to C90. In the absence of such a claim, the fact that it
doesn't diagnose // comments is no worse than the fact that it doesn't
diagnose REM statements.

True; the problem isn't that he has made any claim that lcc-win fully
conforms to C90 or C99. The problem is that he responds so viciously to
anyone pointing out that it doesn't fully conform. Coming from anyone
else, I would consider such a response to be an implicit (and false)
claim that they do fully conform. I don't know what it means coming from
jacob, but he's at least made it clear that it doesn't mean that. My
best guess is that this is his way of saying "I don't care if it doesn't
fully conform", but the vehemence with which he says it belies the "I
don't care" part.

[Keith Thompson]

Harald van Dijk <tr*****@gmail.comwrites:

On Mon, 29 Sep 2008 15:56:09 -0700, vippstar wrote:

>On Sep 29, 10:50 pm, Harald van Dijk <[e-mail]:

[...]

>>How about borrowing from other languages? Allow operators to be used as
functions: +(2, 3) == 2 + 3. Then make pow an operator: pow(2, 3) == 2
pow 3. (I don't necessarily think this is a good idea; I haven't given
it a lot of thought. I like it at first glance though.)

What'd be the type of +?

It wouldn't have a type.

>What would the result of this be:

1 + (2, 3)

In C, as it is defined by ANSI/ISO in the standards, it's 4.

It would remain unaffected. Your point is a good one, but the example
should use unary plus: the value of +(2, 3) is currently already defined
as 3, not 5.

Which is why, if this feature were to be added to the language, you'd
need a distinctive notation for an operator used as a function name.
C++ uses ``operator+(2, 3)'' (though I'm not sure it applies in this
case).

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