good c compiler

K

Kenny McCormack

[QUOTE="jacob navia said:
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.[/QUOTE]

It *does* emit a diagnostic. The diagnostic is a string of zero length.
According carping kuyper, this is OK.
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.
 
K

Keith Thompson

jacob navia said:
James said:
bernard said:
Keith Thompson wrote:
[...]
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?

[...]
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.
 
J

jameskuyper

jacob said:
James said:
bernard said:
Keith Thompson wrote:

[...]
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.
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.
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.
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.
 
J

jameskuyper

Kenny said:
[QUOTE="jacob navia said:
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.[/QUOTE]

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

Ben Bacarisse

jacob navia said:
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.
 
J

jameskuyper

Tristan said:
Greetings.



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

Kenny McCormack

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

lawrence.jones

Mark L Pappin said:
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.
 
K

Kenny McCormack

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

Harald van Dijk

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

Keith Thompson

Harald van Dijk said:
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.
 
C

CBFalconer

jacob said:
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.
 
V

vippstar

... snip ...



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

Harald van Dijk

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

Keith Thompson

CBFalconer said:
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.
 
K

Keith Thompson

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

jameskuyper

Harald said:
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.
 
H

Harald van Dijk

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

Bartc

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

Mark L Pappin

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top