C99 Versus ANSI.

[Richard Heathfield]

jacob navia said:

Given the history of pedantic remarks you use,
it is obvious that you can't refrain.

But if you want it, you are right.

So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.

 

[Guest]

jacob navia said:


So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.

You mean one, right? IBM's? It was mentioned in this thread, and from
http://www-306.ibm.com/software/awdtools/xlcpp/features/:
"The C and the C++ compilers conform to the latest ISO/IEC
International Standards. The C compiler supports the latest ISO C 1999
(International Standard ISO/IEC 9899:1999) standard, also known as C99."

 

[jacob navia]

You mean one, right? IBM's? It was mentioned in this thread, and from
http://www-306.ibm.com/software/awdtools/xlcpp/features/:
"The C and the C++ compilers conform to the latest ISO/IEC
International Standards. The C compiler supports the latest ISO C 1999
(International Standard ISO/IEC 9899:1999) standard, also known as C99."

If you ignore pedantic people, there are MANY more. Intel's, gcc, and
many others are almost 100% conformant. A few irrelevant issues are
a justification fgor pedantic people to scream "NO, there is NONE"

Just ignore them

 

[Keith Thompson]

It is the current C standard, as defined by ANSI/ISO. The old standard
(C89) is now obsolete.

C89 (or, equivalently, C90) is "obsolete" only in a very narrow and
legalistic sense. The C99 standard *offically* supersedes the C90
standard, but it is not widely implemented. The only reliable way to
produce portable C code is to limit yourself to the C90 standard,
while avoiding incompatibilities with C99 (for example, don't use
"restrict" as an identifier, because it's a keyword in C99 but not in
C90). The resulting code, if written carefully, will work correctly
under both C90 and C99 implementations.

C90 is still widely used and widely supported. C99 (by which I mean
the full language defined by the C99 standard) is not.

jacob, you know this perfectly well.

is it portable

Yes. There are compilers for it under linux, windows, and many
other operating systems and implementations. Microsoft doesn't
implement it, but you can find compilers like intel compiler
that implements it. Comeau C/C++ implements C99 also.

There are a very few compilers that *fully* support C99. Intel's
compiler does not, as far as I know; we discussed this here recently.

[snip]

C99 offers most of the all standard (including warts like gets())
and adds significant functionality.

Significance is in the eye of the beholder. C99 has some nice
features, but none that I can't get along without.

If you insist on using the full C99 language, you're going to have to
avoid using any compilers that don't fully support it. That means you
won't be able to use gcc, any Microsoft compiler, or lcc-win32.

 

[Keith Thompson]

Excuse me, I misunderstood "system" as operating system.
Actually, it looks that you meant "compiler system". Well,
my answer stays, gcc implements C99 under unix, and under windows
there is intel compiler, lcc-win32 and Comeau, that actually
also runs under Unix.

That makes for more than two "compiler systems"

It does not, as you know perfectly well.

gcc does not fully support C99. See
<http://gcc.gnu.org/c99status.html> for details. And of course gcc
uses the operating system's C library, so even if the compiler were
100% C99 compliant, the *implementation* would not be on many systems.

I don't believe that Intel's compiler fully supports C99. If you can
demonstrate that it does, please do so.

When I asked you about lcc-win32's C99 support in comp.compilers.lcc
just a few weeks ago, you wrote:
| No, there isn't a listing but I am implementing as time
| permits.
|
| Designated initializers and structure initializers with the
| dot notation are missing.
|
| I am giving priority to the library, that is kind of
| "mostly" finished. I have probably some problems with
| complex numbers, there hasn't been a good testing of that
| part.
|
| Besides the preprocessor is still missing the variable
| arguments feature.

I don't know Comeau's status, and I've never used it.

So that's *at most* one C implementation that fully supports C99.

I am *astonished* that you would claim that lcc-win32 implements C99,
after having explicitly stated that it does not.

And if you consider a compiler that supports only a *subset* of C99 to
be a "C99 compiler", then every conforming C90 compiler is a C99
compiler; after all, C90 is most of C99.

 

[Guest]

I don't believe that Intel's compiler fully supports C99. If you can
demonstrate that it does, please do so.

Having just tested it, I can demonstrate that it does not.

$ cat test.c
int main (void)
{
printf ("Hello, world!\n");
}
$ icc --version
icc (ICC) 9.1 20060816
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.

$ icc -strict-ansi -c99 -Wall test.c -o test
$ ./test
Hello, world!

(C99 requires a diagnostic for syntax errors, and undeclared
identifiers are a syntax error.)

 

[Frederick Gotham]

Keith Thompson posted:

C89 (or, equivalently, C90) is "obsolete" only in a very narrow and
legalistic sense. The C99 standard *offically* supersedes the C90
standard, but it is not widely implemented. The only reliable way to
produce portable C code is to limit yourself to the C90 standard,
while avoiding incompatibilities with C99 (for example, don't use
"restrict" as an identifier, because it's a keyword in C99 but not in
C90). The resulting code, if written carefully, will work correctly
under both C90 and C99 implementations.

I wonder if there are many circumstances in which certain behaviour was
defined by the C89 Standard, but then became undefined by the C99 Standard? I
can think of one instance:

int Func(void) {}

int main(void) { Func(); return 0; }

 

[Guest]

Keith Thompson posted:



I wonder if there are many circumstances in which certain behaviour was
defined by the C89 Standard, but then became undefined by the C99 Standard? I
can think of one instance:

int Func(void) {}

int main(void) { Func(); return 0; }

This is a strictly conforming program in C99.

 

[Frederick Gotham]

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= posted:

This is a strictly conforming program in C99.

Over on comp.lang.c++, we were discussing the idea of a non-void-returning
function not having a return statement. One of the participants claimed that
it was UB in C99 because of the following:

(section 6.8.6.4/1,
a constraint on the return statement): "A return statement without an
expression shall appear only in a function whose return type is void."

However, I read that to mean that the following is broken:

int Func(void) { return; }

rather than the following being broken:

int Func(void) {}

 

[Richard Heathfield]

Harald van D?k said:

Richard Heathfield wrote:


You mean one, right? IBM's? It was mentioned in this thread,

Oops, must have missed that. Okay, one, then.

And presumably the C99 source code is portable between the IBM compiler
and... er... the IBM compiler. Excellent. Nice one, ISO.

 

[Richard Heathfield]

jacob navia said:

If you ignore pedantic people, there are MANY more. Intel's, gcc, and
many others are almost 100% conformant. A few irrelevant issues are
a justification fgor pedantic people to scream "NO, there is NONE"

Just ignore them

Be very wary of any implementor who thinks pedantry is a Bad Thing.

 

[Keith Thompson]

It is business talk.

If you write

This is 100% conforming you are liable if there is the
slightest bug. If you write "some" conformance, you are
not.

Or you might write "some conformance" if you know that your compiler
isn't fully conforming.

If you have some actual knowledge about the Intel compiler's C99
conformance, beyond what's on the web page, perhaps you could share it
with the rest of us. Intel's statement of "some conformance"
certainly isn't enough for us to assume that it's fully conforming.

 

[Keith Thompson]

Richard Heathfield wrote: [...]

So far, then, we have exactly ZERO conforming implementations of C99. So
much for that.

You mean one, right? IBM's? It was mentioned in this thread, and from
http://www-306.ibm.com/software/awdtools/xlcpp/features/:
"The C and the C++ compilers conform to the latest ISO/IEC
International Standards. The C compiler supports the latest ISO C 1999
(International Standard ISO/IEC 9899:1999) standard, also known as C99."

If you ignore pedantic people, there are MANY more. Intel's, gcc, and
many others are almost 100% conformant. A few irrelevant issues are
a justification fgor pedantic people to scream "NO, there is NONE"

Just ignore them

If you ignore pedantic people, you're unlikely to learn anything.

Who are you to decide which issues are irrelevant?

If you want to tell us that some compiler supports most of C99, that's
fine. If you tell us, without qualification, that it supports C99,
and in fact it fails to support some C99 features (such as designated
initializers, structure initializers with the dot notation, and macros
with variable argument lists), then your statement is at best
incomplete, and at worst simply untrue.

As I said elsethread, a conforming C90 compiler is *nearly* a
conforming C99 compiler; C90 is most of C99. If I were to claim that
"gcc -ansi -pedantic" is a C99 compiler (with an unstated assumption
that the features that are in C99 but not in C90 are not
"significant"), I doubt that you would take my statement seriously.

You can write portable conforming C99 code today, simply by avoiding
any C99-specific features. (Such code is also portable conforming C90
code.)

You're a compiler implementer. You *should* be pedantic.

 

[Keith Thompson]

Having just tested it, I can demonstrate that it does not.

$ cat test.c
int main (void)
{
printf ("Hello, world!\n");
}
$ icc --version
icc (ICC) 9.1 20060816
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.

$ icc -strict-ansi -c99 -Wall test.c -o test
$ ./test
Hello, world!

(C99 requires a diagnostic for syntax errors, and undeclared
identifiers are a syntax error.)

It's a constraint violation, not a syntax error, but both constraint
violations and syntax errors require diagnostics.

Perhaps there's some other set of command-line options that cause icc
to be (more nearly) conforming?

 

[Guest]

It's a constraint violation, not a syntax error, but both constraint
violations and syntax errors require diagnostics.

6.5.1p2:
An identiï¬er is a primary expression, provided it has been declared
as designating an
object (in which case it is an lvalue) or a function (in which case it
is a function
designator).77)

77) Thus, an undeclared identiï¬er is a violation of the syntax.

Perhaps there's some other set of command-line options that cause icc
to be (more nearly) conforming?

According to the documentation, -strict-ansi -c99 is enough to get icc
to (attempt to) conform to C99. Does the standard require that an
implementation accurately describe how to invoke it in a conforming
mode?

 

[Andrea Laforgia]

If you ignore pedantic people, there are MANY more.

If you ignore pedantic people, than you will have only an approximate
knowledge of real things. "Almost 100% conformant" is simpy NOT
conformant, so the answer "NO, there is NONE" is really correct if all
the compilers available are ALMOST 100% conformant.

 

[Keith Thompson]

6.5.1p2:
An identifier is a primary expression, provided it has been declared
as designating an object (in which case it is an lvalue) or a
function (in which case it is a function designator).77)

77) Thus, an undeclared identifier is a violation of the syntax.

Interesting. I'll have to take a closer look at that. (My copy of
the standard isn't available at the moment.)

I certainly think of using an undeclared identifier as a semantic
error rather than a syntax error, but sometimes the standard foolishly
disagrees with me. }

According to the documentation, -strict-ansi -c99 is enough to get icc
to (attempt to) conform to C99. Does the standard require that an
implementation accurately describe how to invoke it in a conforming
mode?

Interesting question.

 

[jmcgill]

If you ignore pedantic people

When were you appointed as the person who gets to draw the line between
what's "pedantic" and what's just plain wrong?

 

[jmcgill]

It is business talk.

If you write

This is 100% conforming you are liable if there is the
slightest bug. If you write "some" conformance, you are
not.

Oh really? You think the FSF is afraid of being sued?

 

[Keith Thompson]

Interesting. I'll have to take a closer look at that. (My copy of
the standard isn't available at the moment.)

I certainly think of using an undeclared identifier as a semantic
error rather than a syntax error, but sometimes the standard foolishly
disagrees with me. }

[...]

Yes, the standard agrees with your. (I didn't doubt your quotation, I
just wanted to look at the context.) But I would still question the
way the standard says this.

With a bit more context:

6.5.1 Primary expressions

Syntax

1 primary-expression:
identifier
constant
string-literal
( expression )

Semantics

2 An identifier is a primary expression, provided it has been
declared as designating an object (in which case it is an lvalue)
or a function (in which case it is a function designator).77)

[...]

77) Thus, an undeclared identifier is a violation of the syntax.

So the "Syntax" section clearly says that an identifier is a primary
expression, but the "Semantics" section says this applies only if it's
been declared as designating an object or a function. It's odd that
the "Syntax" section doesn't completely describe the syntax; it seems
to me it would have been more sensible to say that an identifier is
always a primary expression, and the use of an undeclared identifier
is a semantic error, not a syntax error. (Sometimes an aspect of the
syntax can be more easily stated in English rather than in BNF, but it
doesn't seem necessary in this case.)

But as I said, sometimes the standard foolishly disagrees with me. }