ISO C89 and ISO C99

[jrefactors]

When people say C programming language, they mean ISO C89? The latest C
is ISO C99, but
I heard this is not commonly used. What's the differences between ISO
C89 and ISO C99?

Please advise. Thanks

 

[Victor Bazarov]

When people say C programming language, they mean ISO C89? The latest C
is ISO C99, but
I heard this is not commonly used. What's the differences between ISO
C89 and ISO C99?

Ask people who say. When I say C, I usually mean a common subset of C90
and C99.

 

[Chris Hills]

When people say C programming language, they mean ISO C89?

C98 is ANSI C
C90 is ISO C
Identical content as regards the C. the ANSI- C became the ISO-C
document.

The latest C
is ISO C99, but
I heard this is not commonly used.

There are no AFAIK complete C99 implementations. As there will be a C05
it is likely there never will be a C99 compiler.

Certainly no mainstream or industrial compilers that support it apart
from the Tasking Tricore compiler AFAIK.

What's the differences between ISO
C89 and ISO C99?

If you look on http://www.phaedsys.org under the SW Engineering button
there is a link to the differences between C90 and C99.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[E. Robert Tisdale]

jrefactors writes


C89 is ANSI C
C90 is ISO C
Identical content as regards the C.
The ANSI-C became the ISO-C document.

I use it all of the time.

There are, AFAIK, no complete C99 implementations.

There are also no complete C89 implementations
but typical C89 implementations are "closer" to being complete
than typical C99 implementations.

As there will be a C05, it is likely there never will be a C99 compiler.

When (if) there is a C05 standard, it will subsume the C99 standard
and this will be a moot point.

Certainly no mainstream or industrial compilers that support it
apart from the Tasking Tricore compiler AFAIK.

Your information is obsolete.
I use several C99 compilers

Intel(R) C++ Compiler 7.1 and 8.1 (both accept C99),
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-42), etc.

I never have had occasion to use the missing C99 features
so, as far as I'm concerned, these implementations are complete.

 

[Chris Hills]

I use it all of the time.

Which does not change the statement that it is not commonly used.
I know 20 people still using PLM but I would not say it is common.

There are also no complete C89 implementations
but typical C89 implementations are "closer" to being complete
than typical C99 implementations.


When (if) there is a C05 standard, it will subsume the C99 standard
and this will be a moot point.

Not at all.
The point is that in the period 1999 to 2004 there were no C99 compliant
compilers. From 2005 there may be C05 compilers but these will not be
C99 compilers.

Your information is obsolete.
I use several C99 compilers

Intel(R) C++ Compiler 7.1 and 8.1 (both accept C99),
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-42), etc.

I never have had occasion to use the missing C99 features
so, as far as I'm concerned, these implementations are complete.

Then ALL C compilers are C99 compliant as far as I am concerned because
I have never used the missing parts.

As you point out there are no completely conforming C99 compilers.
There are some completely conforming C90 compilers.

I thought that the GCC were not fully C99 and in any event GCC used it's
own standard?



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[E. Robert Tisdale]

As you point out there are no completely conforming C99 compilers.
There are some completely conforming C90 compilers.

Name ten.

 

[Greg Comeau]

As you point out there are no completely conforming C99 compilers.
There are some completely conforming C90 compilers.

Comeau + Dinkumware provides as much C99ness as the others
provide C90ness, if not more, and furthermore, also provides
C90ness and C++03ness. We look forward to 05, whatever it may
or may not yield in new standards.

 

[E. Robert Tisdale]

Comeau + Dinkumware provides as much C99ness
as the others provide C90ness, if not more
and furthermore, also provides C90ness and C++03ness.
We look forward to 05,
whatever it may or may not yield in new standards.

Hi Greg,

Why don't you claim that your compilers comply with these standards?
Do you know that they do *not* comply with certain specifications
of the respective standards? And, if so, can you enumerate them?
Or is this simply a legal consideration in case bugs
or subtle misinterpretations of the standards are discovered?

 

[Sniper1]

When people say C programming language, they mean ISO C89?

Outside of this newsgroup, most people still say "ANSI C", usually
meaning portable C89. In the broader market, they seem to be far
less pedantic about "portable" than in c.l.c. In fact, sometimes
recruiters or even hiring managers will have their eyes glaze over
at the phrase "ISO C" but think they understand exactly what "ANSI
C" means.

The latest C is ISO C99, but I heard this is not commonly used.

It is not commonly used, for lack of compiler support in most
cases.

What's the differences between ISO C89 and ISO C99?

There are quite a few, Harbison & Steele 5th Ed. does a decent
job of laying them out if you are not willing to dig through
the standards for yourself. However, there is very little
that one might want to do that is provided in C99 but not
available in C89.

 

[Greg Comeau]

Why don't you claim that your compilers comply with these standards?
Do you know that they do *not* comply with certain specifications
of the respective standards? And, if so, can you enumerate them?
Or is this simply a legal consideration in case bugs
or subtle misinterpretations of the standards are discovered?

Minus what it even means to say so, and that I don't
feel it is always my position to say so, we offer
a diversity of implementations on a diversity of
platforms, and especially in the custom port cases,
such a claim may not always be true.

In September this was offered:

|Newsgroups: comp.std.c
|From: "Barry E. Hedquist" <[email protected]>
|Date: Fri, 10 Sep 2004 17:51:34 GMT
|Local: Fri, Sep 10 2004 10:51 am
|Subject: Re: C 99 compiler access
|
|We validated a combination of Dinkumware's Library
|and EDG's front end. I believe Comeau uses the
|EDGfront end.
|
|see: www.peren.com/pages/cvsa_isocvpl.htm

I'd offer a "tinyurl" to the above post, but I seem
to be getting beta url's for google groups this week,
so don't know if/when such a link would break.
Anyway, Barry is correct. If you look at the
peren.com link Barry gave above, you'll see that
Perennial has validated EDG, and Dinkumware, which
mean that they have passed all tests. It also
passes all Plum Hall validations. We are derived
from EDG, which as just mentioned is certifiably conforming,
so putting 2 and 2 together means we have configurations
which can match that, for instance, some of our
generally available ports for Windows and LINUX.
As does Dinkumware.

 

[Chris Torek]

(I have no idea why this is cross-posted.)

Outside of this newsgroup, most people still say "ANSI C", usually
meaning portable C89. In the broader market, they seem to be far
less pedantic about "portable" than in c.l.c. In fact, sometimes
recruiters or even hiring managers will have their eyes glaze over
at the phrase "ISO C" but think they understand exactly what "ANSI
C" means.

Which, of course, means they do not, after all.

To be completely explicit, one might use these phrases:

A) ANSI X3.159-1989. This is the original 1989 C standard, dated
December 1989, with Rationale. The main body of the language
is described in section 3, and the "C library" -- stdio,
<string.h> functions, and so on -- in section 4.

B) ISO 9899:1990. This is the original ISO C standard. "ANSI"
is the American National Standards Institute, so the international
crowd have to have their own standards with their own, different,
numbering system. They simply adopted ANSI's 1989 standard,
removed the Rationale, and renumbered the sections (calling
them "clauses" instead). With very few exceptions you can just
add three, so that most of the language is described in section
-- er, "clause" -- 6, and the "C library" part in section 7.

C) ISO 9899:1999. This is the newfangled "C99" standard, with
its Variable Length Arrays, Flexible Array Members, new keywords
like "restrict" and "_Bool", new semantics for the "static"
keyword, new syntax to create anonymous aggregates, new
complex-number types, hundreds of new library functions, and
so on.

The new ISO standard was immediately "back-adopted" by ANSI. I
have not seen any official "ANSI-sanctioned" claim about this, but
given the usual numbering systems, I would expect this to be ANSI
Standard number X3.159-1999. (The numbering system is pretty
obvious: a standard, once it comes out, gets a number --
X<digit>.<sequence> for ANSI, or just a number for ISO -- and a
suffix indicating year of publication. An update to an existing
standard reuses the number, with the new year.)

Although X3.159-1989 and 9899:1990 have different years and section
numbering, they are effectively identical, so "C89" and "C90" really
refer to the same language. Hence you can say either "C89" or
"C90" and mean the same thing, even to those aware of all the
subtleties.

There were also several small revisions to the original 1990 ISO
standard: "Normative Addendum 1", and two "Technical Corrigenda"
(numbered; giving Technical Corrigendum 1 and TC2). The two TCs
are considered to be "bug fixes" for glitches in the wording of
the standard, while NA1 is an actual "change". In practice, the
TCs do not really affect users, while NA1 adds a whole slew of
functions that people can use, so NA1 really is more significant.
NA1 came out in 1994, so one might refer to "ISO 9899:1990 as
modified by NA1" as "C94". I have seen it called "C95", too.

[snipped: other observations on differencs between C89/C90 and C99]

 

[E. Robert Tisdale]

Minus what it even means to say so
and that I don't feel it is always my position to say so,
we offer a diversity of implementations on a diversity of platforms
and especially in the custom port cases,
such a claim may not always be true.


In September this was offered:

|Newsgroups: comp.std.c
|From: "Barry E. Hedquist" <[email protected]>
|Date: Fri, 10 Sep 2004 17:51:34 GMT
|Local: Fri, Sep 10 2004 10:51 am
|Subject: Re: C 99 compiler access
|
|We validated a combination
|of Dinkumware's Library and EDG's front end.
|I believe Comeau uses the EDGfront end.
|
|see: www.peren.com/pages/cvsa_isocvpl.htm

I'd offer a "tinyurl" to the above post, but I seem
to be getting beta url's for google groups this week,
so don't know if/when such a link would break.
Anyway, Barry is correct. If you look at the
peren.com link Barry gave above, you'll see that
Perennial has validated EDG, and Dinkumware,
which mean that they have passed all tests.
It also passes all Plum Hall validations. We are derived
from EDG, which as just mentioned is certifiably conforming,
so putting 2 and 2 together means we have configurations
which can match that, for instance, some of our
generally available ports for Windows and LINUX.
As does Dinkumware.

Evidently, you are advocating some kind of
"independent validation and/or certification"
of compliant implementations.
The Perennial ISO C99 CVSA validated products list:

Dinkumware, Ltd.,
Edison Design Group and
Lund Multiprocessor Compiler Co, AB

is very short and it doesn't mention Comeau explicitly.
I'm not sure that most C++ programmers are qualified
to draw the inference that you have drawn
about the compliance of any given Comeau configuration.

The other question is, "Should C programmers wait
until they can get a validated C99 compiler
before they begin using any of the new C99 features?"
"Should C programmers who need to write portable code
wait until there are validated C99 compilers
for *all* of the possible target platforms
before they begin using any of the new C99 features?"

 

[Greg Comeau]

Evidently, you are advocating some kind of
"independent validation and/or certification"
of compliant implementations.

Just offering a data point, not advocation per se.

The Perennial ISO C99 CVSA validated products list:

Dinkumware, Ltd.,
Edison Design Group and
Lund Multiprocessor Compiler Co, AB

is very short and it doesn't mention Comeau explicitly.
I'm not sure that most C++ programmers are qualified
to draw the inference that you have drawn
about the compliance of any given Comeau configuration.

That's probably so.

The other question is, "Should C programmers wait
until they can get a validated C99 compiler
before they begin using any of the new C99 features?"

"Should C programmers who need to write portable code
wait until there are validated C99 compilers
for *all* of the possible target platforms
before they begin using any of the new C99 features?"

I can't answer that. Each programmer needs to do so
for their own needs, projects, tradeoffs, legacy, etc.
That said, certainly many don't need to wait,
nor should they.

 

[Dave Thompson]

To be completely explicit, one might use these phrases:

A) ANSI X3.159-1989. <snip>

B) ISO 9899:1990. <snip>

C) ISO 9899:1999. This is the newfangled "C99" standard, <snip>

To be completely explicit, ISO/IEC. SC22 and its working groups are
under JTC1, the first and only Joint Technical Committee between ISO
and IEC. In practice people forget about IEC, but I just love saying
"electrotechnical" -- it's almost as good as "supercalifrag-etc.".

The new ISO standard was immediately "back-adopted" by ANSI. I

Not quite immediate. C99 just barely lived up to its working name of
C9X, being adopted in Nov. '99 as I recall. There was some hangup in
ANSI procedures, and the official vote didn't go through until I think
May or June of '00, though there was no real doubt it would as the
technical-level groups had already agreed. I didn't get the details; I
think they had to allow some fixed time for objections even though
there weren't going to be any. For comparison, AIUI such a delay is
required by law for US government standards, cf. FIPS(es) from NBS ^W
NIST. Though ANSI isn't gubmint-al.

have not seen any official "ANSI-sanctioned" claim about this, but
given the usual numbering systems, I would expect this to be ANSI
Standard number X3.159-1999. (The numbering system is pretty

At first they called it ANSI/ISO/IEC 9899:1999 -- as for many other
ANSI adoptions of (existing) international standards. Now that X3 has
become INCITS, it seems to be INCITS/ISO/IEC 9899:1999.

obvious: a standard, once it comes out, gets a number --
X<digit>.<sequence> for ANSI, or just a number for ISO -- and a

Actually <committee>.<sequence> where committee was one letter and a
(always? usually?) one digit number. X3 was computers and data
processing. T1 was telecoms, and there were a wide variety of others
-- IIRC bicycle helmets were under Z6, and steam boilers were
somewhere in the vicinity of H. There used to be a rather interesting
list on their website that I can't find anymore, as they seem to have
changed over to industry organizations having their own names (well,
acronyms) instead of <ltr><num> codes: X3 (which was actually CBEMA)
-> INCITS is only one case.

Some ISO numbers have a part, like 9945-1 and 9945-2, and closer to
home 1539-1 to -3 for Fortran. I don't recall any ANSI (original)
standards that had parts, but that doesn't mean there weren't any.

suffix indicating year of publication. An update to an existing
standard reuses the number, with the new year.)

Right. But this isn't considered an update to X3.159, it's considered
an update to ISO/IEC 9899. Even though technically identical.

<snip rest>

- David.Thompson1 at worldnet.att.net