ISO C89 and ISO C99

[Chris Torek]

Re: ISO C89 and ISO C99

(I have no idea why this is cross-posted.)
[color=blue]
>In article <1102697362.851 000.205840@f14g 2000cwb.googleg roups.com>,
>jrefactors@hot mail.com says...[color=green]
>> When people say C programming language, they mean ISO C89?[/color][/color]

In article <MPG.1c2411e94d b26963989693@ne ws.verizon.net>
Sniper1 <spamtrap@examp le.net> wrote:[color=blue]
>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.[/color]

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>.<seque nce> 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.
[color=blue]
>[snipped: other observations on differencs between C89/C90 and C99][/color]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[E. Robert Tisdale]

Re: ISO C89 and ISO C99

Greg Comeau wrote:
[color=blue]
> E. Robert Tisdale wrote:
>[color=green]
>>Greg Comeau wrote:
>>[color=darkred]
>>>Chris Hills wrote:
>>>
>>>>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.[/color]
>>
>>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 misinterpretati ons of the standards are discovered?[/color]
>
> 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" <b...@peren.com >
> |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.[/color]

Evidently, you are advocating some kind of
"independen t 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]

Re: ISO C89 and ISO C99

In article <cpg47k$s02$1@n ntp1.jpl.nasa.g ov>,
E. Robert Tisdale <E.Robert.Tisda le@jpl.nasa.gov > wrote:[color=blue]
>Greg Comeau wrote:[color=green]
>> E. Robert Tisdale wrote:[color=darkred]
>>>Greg Comeau wrote:
>>>>Chris Hills wrote:
>>>>>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.
>>>
>>>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 misinterpretati ons of the standards are discovered?[/color]
>>
>> 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" <b...@peren.com >
>> |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.[/color]
>
>Evidently, you are advocating some kind of
>"independen t validation and/or certification"
>of compliant implementations .[/color]

Just offering a data point, not advocation per se.
[color=blue]
>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.[/color]

That's probably so.
[color=blue]
>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?"[/color]

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.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Dave Thompson]

Re: ISO C89 and ISO C99

On 11 Dec 2004 18:41:11 GMT, Chris Torek <nospam@torek.n et> wrote:
<snip>[color=blue]
> 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>
>[/color]
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
"electrotechnic al" -- it's almost as good as "supercalif rag-etc.".
[color=blue]
> The new ISO standard was immediately "back-adopted" by ANSI. I[/color]

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.
[color=blue]
> 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[/color]

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.
[color=blue]
> obvious: a standard, once it comes out, gets a number --
> X<digit>.<seque nce> for ANSI, or just a number for ISO -- and a[/color]

Actually <committee>.<se quence> 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.
[color=blue]
> suffix indicating year of publication. An update to an existing
> standard reuses the number, with the new year.)
>[/color]
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.ne t