C Compilers

[Keith Thompson]

#include <stdio.h>

int main(void)
{
int a = 10;
int b = 10;
int c = a //* would anyone actually write this? */ b
;
printf("%d\n", c);
return 0;
}

In C90, this must print 1 and a newline. In C99, it must print 10 and
a newline.

Then I'd be curious to see how lcc-win handle this:

#include <stdio.h>
int main(void)
{
int inline = 10;
int restrict = 10;
int c = inline //* would anyone actually write this? */ restrict
;
printf("%d\n", c);
return 0;
}

I suspect it would report several syntax errors ("gcc -std=c99"
does so).

 

[Keith Thompson]

jameskuyper a écrit :

Then, there are all the headers that must be backported to C89.
All of them, since many functions have been added, changed, whatever.
Each header must be re-read and be rewritten for C90.

Long long support must be eliminated, not to speak about int128.

Then there are all the library that needs to be re-read to see
if there are any incompatibilities with C99.

The already complex code for structure initialization must be
back ported to avoid C99 stuff, obviously without introducing
new bugs.

This is like 2-3 weeks of work full time.

For what?

That's what you'd have to do to make lcc-win a fully conforming C90
compiler -- *if* you chose to do so.

I do not see the point.

And that's fine. Nobody (with the possible exception of a single
troll I won't name) has said that you must, or even that you should,
make lcc-win fully conform to C90.

Hmm. You say that you'd have to drop int128 support to conform
to C90. Doesn't that imply that int128 support also interferes
with C99 compliance (neither C90 or C99 has int128)? On the other
hand, if int128 isn't visible unless you add #include <int128.h>,
then it probably doesn't interfere with C90 compliance either.

Just to be clear, my comment above that "neither C90 or C99 has
int128" refers to that specific name; both C90 and C99 permit
128-bit integers.

 

[Nobody]

lcc-win will compile all C90. The *only* problem with C90 is that
// comments will NOT be rejected.

Does it compile this well-known test case correctly:

int a = b //* comment */ c
;

?

If not, then it doesn't compile all of C90. It may compile "enough" of it,
for some definitions of "enough". But then one person's definition of
"enough" may not be be the same as another's. OTOH, there's no ambiguity
regarding "conformant"; either it is or it isn't. This is why we have
standards.

Since // is a syntax error in most
cases I do not see why I should work to implement this. As far as I
remember C90 is implemented as far as it does not contradict C99.

IOW, not only are you *not* claiming C90 conformance, you are specifically
stating that it's non-conformant.

To say that C90 is not implemented is a gross distortion of the facts.

No, it's just a simple fact. If you don't want to offer C90 (or C99)
conformance, then don't. But don't try to muddy the waters about what
lcc-win does or does not provide.

And your comments elsewhere in this thread indicate that non-conformance
goes much, much deeper than just // comments. C99 introduces a lot of new
identifiers (and two new keywords) which are available for the user in C90.

Yes, I believe is conformant.

In light of your previous statements, the only way that you can honestly
believe that it is conformant is by deceiving yourself as to what
"conformant" means.

Hint: it *doesn't* mean "doesn't deviate from the standard by much". It
means that it doesn't deviate from the standard *at all*.

If there is any problem tell me and I will fix it.

Why? If you don't address the issues which you already know about, lcc-win
still isn't going to be conformant if you fix every other issue.

Now, if you don't want to provide conformance, no-one is going to try to
force you to. But if you blithely list various ways in which it doesn't
conform then try to claim that it is actually conformant, don't be
surprised when people get annoyed at you for setting yourself up as an
arbiter of what "conformance" means or what the standards dictate.

 

[Nobody]

Then I'd be curious to see how lcc-win handle this:

#include <stdio.h>
int main(void)
{
int inline = 10;
int restrict = 10;
int c = inline //* would anyone actually write this? */ restrict
;
printf("%d\n", c);
return 0;
}

I suspect it would report several syntax errors ("gcc -std=c99"
does so).

OTOH, "gcc -std=c89" compiles it correctly ("gcc" alone doesn't, as
the default dialect is -std=gnu89, which treats "inline" as a keyword).

 

[Flash Gordon]

Seebs a écrit :

As everybody knows, implementing a thing like C99 with only one guy is
not a matter of
NOW it is implemented

5 minutes ago it wasn't.

Ah, but it is, and you are now stating that the 5 minutes (and all the
hard work before it) is completed.

It is just years of bug fixing. True, I am not the kind of
person to boast around:

I have everything needed for C99.

Which is a very good thing and was not the case on the last post I
remember where you made a clear statement about C99. It makes your
compiler far more interesting.

But what is needed now are just bug fixes. This is a monstruos undertaking:
C99 library: I have done all new functions
C99 preprocessor: bugs may remind in the VA_ARGS macro.
C99 syntax. The simple structure/array initialization of C90
is gone, replaced by a much more complex syntax...
I have surely some bugs there.

<snip>

OK, there may be bugs but you are currently not aware of any. There may
be bugs in any piece of software, and as everyone here knows a C
compiler is complex enough that it is almost certain to have at least
one bug. Not just your C compiler, but *every* C compiler!

So I will happily now add your compiler to the list of C99 compilers. In
fact, I *have* done this here http://clc-wiki.net/wiki/C_resources:Compilers

I would also suggest that you put on your web site that with the -ansic
switch it conforms to C99. After you've done that you can add a link to
your compliance statement on the above page.

Note that I'm not going to be testing your compiler, I have too much
work to do! I'm also not going to change that page simply because
someone happens to trip over a bug since, as I say, all complex software
has bugs.

 

[jameskuyper]

jameskuyper a �crit :

Then, there are all the headers that must be backported to C89.
All of them, since many functions have been added, changed, whatever.
Each header must be re-read and be rewritten for C90.

Long long support must be eliminated, not to speak about int128.

Then there are all the library that needs to be re-read to see
if there are any incompatibilities with C99.

The already complex code for structure initialization must be
back ported to avoid C99 stuff, obviously without introducing
new bugs.

This is like 2-3 weeks of work full time.

For what?

I do not see the point.

There is no point, unless you want to claim conformance. If you do
want to claim conformance, then you should make those changes. There's
nothing wrong with not wanting to claim conformance. There is
something wrong with claiming conformance if you haven't actually
achieved it.

 

[jameskuyper]

You are talking about different things.

There is a language compliance test like Perennial and Plum hall
then you have the other tests including random program generation to
test all possible (or a large random selection)

I seriously doubt that they test all possible cases; if they did, the
first such test that was ever attempted would still be running when
the Sun enters it's white-dwarf phase. It can, at best, be a large
random selection of cases, which is precisely my point.

I presume also that such tests only confirm generation of required
diagnostics, and not generation of an executable with the correct
behavior when the behavior is well defined. The "correct behavior"
would, first of all, be hard to determine for sufficiently large
randomly generated programs, and secondly is quite likely to include
infinite loops, which would make verification a rather slow
process.

... of combinations. There
is more to compiler testing that language syntax and semantics

I'm willing to believe that; but the standard only talks about syntax
and semantics. Such important points as efficiency, clarity and
correctness of diagnostic messages, and ease of use, aren't relevant
to conformance testing, even though they are very relevant to testing
a compiler.

 

[Chris H]

In message <[email protected]

I'm willing to believe that; but the standard only talks about syntax
and semantics.

Of course. It is a language specification

Such important points as efficiency, clarity and
correctness of diagnostic messages, and ease of use, aren't relevant
to conformance testing, even though they are very relevant to testing
a compiler.

I agree.

 

[Nick Keighley]

Nor is it fair to test it and shout "compliant" in the event that it
happens to pass.

I had something tested for compliance once by a third party.
The certificate read

"XYZ has run all tests successfully and has not been shown to be non-
compliant"

 

[Nick Keighley]

Richard Heathfield a écrit :



This is just not true (as many other things that heathfield says)

so you are claiming that lcc-win32 is a fully compliant C99 compiler.
Do you say so on the web site.

[must not get sucked in, must not..]

 

[gwowen]

1) Do you believe that lcc-win32 conforms to ISO/IEC 9899:1990?
2) Do you believe that lcc-win32 conforms to ISO/IEC 9899:1999?

Q Software Solution, GmbH make the following claim:
"Lcc-win32 implements the full ANSI-C standard,
plus some extensions to accomodate for the new 'mmx'
instruction set available for the x86 architecture."
which suggests conformance to ANSI X3.159-1989 [0]

They also describe Jacob Navia as
"The C wizard in our team.
You'll hardly find more years of C experience."[1]

[0] http://www.q-software-solutions.de/products/lcc-win32/objectives.shtml
[1] http://www.q-software-solutions.de/about.shtml

 

[jacob navia]

Richard Heathfield a écrit :

Richard Heathfield a écrit :

As far as I can tell, [lcc-win32's] author has never
formally claimed its conformance with any ISO C
Standard, either C90 or C99.
This is just not true (as many other things that heathfield says)

so you are claiming that lcc-win32 is a fully compliant C99
compiler. Do you say so on the web site.

Jacob Navia has been asked many times to clarify his conformance
claims, and has never (as far as I am aware) done so unambiguously.
What makes you think this time will be different?

Still, it's worth a try.

Jacob, if you're reading, could you please answer these two questions
YES or NO:

1) Do you believe that lcc-win32 conforms to ISO/IEC 9899:1990?

I have found a version of lcc-win from 1999. Since the C standard
was not even there, it is fully conforming to ANSI C90. By the
way of test I compiled your test program, and everything is OK.

I have found too, an old version of the C headers. I have just to
get around to find an old version of the linker of 1999, where
it linked with crtdll.dll. Since that version of the microsoft
run time is fully C90 compliant, I have the whole system.

So, I can say without any problems that I can furnish an lcc-win
version that is fully C90 compliant.

2) Do you believe that lcc-win32 conforms to ISO/IEC 9899:1999?

Yes, I think that I can say that. For interested customers I can
furnish bug corrections if they find any. For people without
maintenance contract, bugs will be fixed as time permits.

 

[Keith Thompson]

1) Do you believe that lcc-win32 conforms to ISO/IEC 9899:1990?
2) Do you believe that lcc-win32 conforms to ISO/IEC 9899:1999?

Q Software Solution, GmbH make the following claim:
"Lcc-win32 implements the full ANSI-C standard,
plus some extensions to accomodate for the new 'mmx'
instruction set available for the x86 architecture."
which suggests conformance to ANSI X3.159-1989 [0]

That's an interesting statement. Most people use the term "ANSI C" to
refer to ANSI X3.159-1989 (C89), but in fact ANSI has officially
adopted ISO/IEC 9899:1999 (C99) as an ANSI standard, superseding
all previous C standards.

I also note that lcc-win's own "-ansic" option is intended to cause
it conform to the C99 standard ("-isoc" would have been clearer).

It's likely that the quoted statement was made by someone who
doesn't know the difference.

www.q-software-solutions.de isn't responding at the moment, so I
can't see the context in which the statement is made.

[...]

 

[Keith Thompson]

Richard Heathfield a écrit : [...]

1) Do you believe that lcc-win32 conforms to ISO/IEC 9899:1990?

I have found a version of lcc-win from 1999. Since the C standard
was not even there, it is fully conforming to ANSI C90. By the
way of test I compiled your test program, and everything is OK.

Which test program are you referring to?

Does this version of lcc-win diagnose // as a syntax error? Does it
diagnose "long long" as a syntax error?

I have found too, an old version of the C headers. I have just to
get around to find an old version of the linker of 1999, where
it linked with crtdll.dll. Since that version of the microsoft
run time is fully C90 compliant, I have the whole system.

So, I can say without any problems that I can furnish an lcc-win
version that is fully C90 compliant.

Is that version available for download and/or purchase?

Yes, I think that I can say that. For interested customers I can
furnish bug corrections if they find any. For people without
maintenance contract, bugs will be fixed as time permits.

You recently mentioned a problem with compound literals. Has that
been corrected? (I'm not entirely sure whether I'd consider that
a bug or a missing feature, but I'll accept that it's merely a bug.)

jacob, if you really have a conforming C99 compiler, that's a rare
thing and a fairly momentous event. I'm quite surprised that you
wouldn't mention it until you were prodded. I don't currently
have a system on which I can install it; if I did, I would do so.
(Can it be used under WINE on Linux?)

 

[Chris H]

1) Do you believe that lcc-win32 conforms to ISO/IEC 9899:1990?
2) Do you believe that lcc-win32 conforms to ISO/IEC 9899:1999?

Q Software Solution, GmbH make the following claim:
"Lcc-win32 implements the full ANSI-C standard,
plus some extensions to accomodate for the new 'mmx'
instruction set available for the x86 architecture."
which suggests conformance to ANSI X3.159-1989 [0]

That's an interesting statement. Most people use the term "ANSI C" to
refer to ANSI X3.159-1989 (C89),

Not in my experience they use "ANSI C" to mean "standard C"
Most people have no real idea what ANSI C really means and much less ISO
C

 

[jacob navia]

Richard Heathfield a écrit :

But according to you, it fails to diagnose BCPL-style comments, and
therefore is not conforming. Up until now, I thought your position
was that you were not interested in C90 conformance, so this comments
issue was irrelevant. Now it seems that you *are* claiming C90
conformance, in which case it becomes relevant.

F:\backups\oldversions\lcc90\test>type test.c
int main(void)
{
int inline = 10;
int restrict = 10;
int c = inline //* would anyone actually write this? */ restrict
;
printf("%d\n", c);
return 0;
}
F:\backups\oldversions\lcc90\test>..\lcc90 test.c
Chars read: 190,Total compilation time = 0.003 sec.

F:\backups\oldversions\lcc90\test>lcclnk test.obj

F:\backups\oldversions\lcc90\test>test
1
F:\backups\oldversions\lcc90\test>type t1.c
long long m;
// This is not a comment

F:\backups\oldversions\lcc90\test>..\lcc90 t1.c
Error t1.c 1 invalid use of `long'
Error t1.c 2 unrecognized declaration
Error t1.c 2 unrecognized declaration
Error t1.c 2 syntax error; found `is' expecting `;'
Error t1.c 2 syntax error; found `not' expecting `;'
Error t1.c 2 syntax error; found `a' expecting `;'
Error t1.c 2 syntax error; found `comment' expecting `;'
Error t1.c 2 syntax error; found `end of input' expecting `;'
Chars read: 40,Total compilation time = 0.003 sec.
8 errors, 0 warnings
F:\backups\oldversions\lcc90\test>


Everything is working as it should. I will update the driver, adding
a new flag (-ansic90) that, if given, will call lcc90 and link with the
old linker producing an executable 32 bits.

o No long long support (see above)
o no long double support, long double is just an alias for double
o no optimizer
o no support for anything that is not in C90: printf is a C90 printf,
all other functions are just C90
o no exception handling support.

Still, there is support for _stdcall. This is an implementation
reserved identifier so it doesn't really matter.

The headers are not compliant since there are probably some extra
functions in them. I will eliminate them as time permits.

It is not a toy however. It still compiles itself. Performance is
about 25-30% of that of lcc-win.

 

[jameskuyper]

Richard Heathfield a �crit : ....

I have found a version of lcc-win from 1999. Since the C standard
was not even there, it is fully conforming to ANSI C90. ...

Do you know that it was fully conforming with C90, or are you merely
assuming conformance because of the date from which you retrieved it?
Your wording implies the latter; if so, that might not be a good
assumption. The 1999 version might, unless you have reason to believe
otherwise, have extensions that are incompatible with C90. In
particular, many vendors had already started implementing parts of C99
as extensions, long before the standard was officially approved - did
you do anything of that sort?

Conforming extensions are no problem, and as long as it has a mode
where all non-conforming extensions are turned off, that's not a
problem, either. However, the problem with your current version is
that it has a few C99 feature implemented as non-conforming C90
extension that cannot be turned off. Do you know that this 1999
version of lcc-win doesn't suffer from similar problems?

Note also that Richard Heathfield's question was about lcc-win32; your
answer was about lcc-win. Can the lcc-win implementation you've found
be considered a version of lcc-win32?

 

[jacob navia]

jameskuyper a écrit :

Do you know that it was fully conforming with C90, or are you merely
assuming conformance because of the date from which you retrieved it?

At that time there were only 5 years of work in lcc-win.

I worked mainly in the assembler, linker and the IDE+debugger. The only
feature I added was _stdcall.

Your wording implies the latter; if so, that might not be a good
assumption. The 1999 version might, unless you have reason to believe
otherwise, have extensions that are incompatible with C90. In
particular, many vendors had already started implementing parts of C99
as extensions, long before the standard was officially approved - did
you do anything of that sort?

Well, long long support isn't there, but I may check with the version of
95 doing a diff.

Conforming extensions are no problem, and as long as it has a mode
where all non-conforming extensions are turned off, that's not a
problem, either. However, the problem with your current version is
that it has a few C99 feature implemented as non-conforming C90
extension that cannot be turned off. Do you know that this 1999
version of lcc-win doesn't suffer from similar problems?

Surely not. None of the compiler was in any way modified to C99
since I did not even have the C99 standard at that time.

Note also that Richard Heathfield's question was about lcc-win32; your
answer was about lcc-win. Can the lcc-win implementation you've found
be considered a version of lcc-win32?

Of course. I will add it to the general distribution as "lcc-win light"



It is incredible small (350K), and very fast when compiled with lcc-win
and using the optimizer. The generated code isn't GREAT but with today's
machines it is much faster than the p4 I had in 99.

 

[Keith Thompson]

So much for yes or no.


But according to you, it fails to diagnose BCPL-style comments, and
therefore is not conforming. Up until now, I thought your position
was that you were not interested in C90 conformance, so this comments
issue was irrelevant. Now it seems that you *are* claiming C90
conformance, in which case it becomes relevant.

[...]

He's said that the current version of lcc-win does not diagnose //
comments. I don't recall that he's ever made a similar statement
about the 1999 version of lcc-win, and based on his later followup it
appears that it does handle // in accordance with the C90 standard.

 

[Keith Thompson]

Richard Heathfield a écrit : [...]
F:\backups\oldversions\lcc90\test>type test.c
int main(void)
{
int inline = 10;
int restrict = 10;
int c = inline //* would anyone actually write this? */ restrict
;
printf("%d\n", c);
return 0;
}
F:\backups\oldversions\lcc90\test>..\lcc90 test.c
Chars read: 190,Total compilation time = 0.003 sec.

F:\backups\oldversions\lcc90\test>lcclnk test.obj

F:\backups\oldversions\lcc90\test>test
1
F:\backups\oldversions\lcc90\test>type t1.c
long long m;
// This is not a comment

F:\backups\oldversions\lcc90\test>..\lcc90 t1.c
Error t1.c 1 invalid use of `long'
Error t1.c 2 unrecognized declaration
Error t1.c 2 unrecognized declaration
Error t1.c 2 syntax error; found `is' expecting `;'
Error t1.c 2 syntax error; found `not' expecting `;'
Error t1.c 2 syntax error; found `a' expecting `;'
Error t1.c 2 syntax error; found `comment' expecting `;'
Error t1.c 2 syntax error; found `end of input' expecting `;'
Chars read: 40,Total compilation time = 0.003 sec.
8 errors, 0 warnings
F:\backups\oldversions\lcc90\test>

Looks good, but ...

Everything is working as it should. I will update the driver, adding
a new flag (-ansic90) that, if given, will call lcc90 and link with the
old linker producing an executable 32 bits.

Ok. I'll note that nobody here has said that you *should* provide a
C90-compliant compiler; we've merely asked whether you have one, and I
for one would have been perfectly satisified with an answer of "no".
But if you choose to do so, that's great.

o No long long support (see above)
Ok.

o no long double support, long double is just an alias for double

That might not be a practical problem for most users, but it's
likely to be a conformance issue. It's perfectly legal for double
and long double to have the same size and representation, but they
must be treated as distinct types.

This translation unit:

double x;
long double *p = &x;

violates a constraint, since double* and long double* are incompatible
types. A compiler that doesn't issue a diagnostic is not 100%
conforming to either C90 or C99.

Note that this is not a C99-specific issue. If the current lcc-win
doesn't issue a diagnostic, that's also a bug, which you can fix or
not as you see fit.

o no optimizer

Ok, not a conformance issue.

o no support for anything that is not in C90: printf is a C90 printf,
all other functions are just C90
Ok.

o no exception handling support.

Ok, but I'm not sure why you mention this.

Still, there is support for _stdcall. This is an implementation
reserved identifier so it doesn't really matter.

It's reserved for use with file scope (C90 7.1.3, C99 7.1.3).
The following program is strictly conforming (but poor style)
in both C90 and C99:

int main(void)
{
int _stdcall = 0;
return _stdcall;
}

If either version of lcc-win fails to compile it, that's a
conformance failure.

The headers are not compliant since there are probably some extra
functions in them. I will eliminate them as time permits.

Fair enough.

It is not a toy however. It still compiles itself. Performance is
about 25-30% of that of lcc-win.

Are you planning to make this version available for download and/or
purchase? I'm not saying you should or shouldn't, I'm just curious.