ISO C89 and ISO C99

Discussion in 'C++' started by jrefactors, Dec 10, 2004.

  1. jrefactors

    jrefactors Guest

    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
    jrefactors, Dec 10, 2004
    1. Advertisements

  2. Ask people who say. When I say C, I usually mean a common subset of C90
    and C99.
    Victor Bazarov, Dec 10, 2004
    1. Advertisements

  3. jrefactors

    Chris Hills Guest

    C98 is ANSI C
    C90 is ISO C
    Identical content as regards the C. the ANSI- C became the ISO-C
    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.
    If you look on under the SW Engineering button
    there is a link to the differences between C90 and C99.

    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
    /\/\/ \/\/
    Chris Hills, Dec 10, 2004
  4. I use it all of the time.
    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.
    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.
    E. Robert Tisdale, Dec 10, 2004
  5. jrefactors

    Chris Hills Guest

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

    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 /\/\/\/\/\
    /\/\/ \/\/
    Chris Hills, Dec 10, 2004
  6. Name ten.
    E. Robert Tisdale, Dec 11, 2004
  7. jrefactors

    Greg Comeau Guest

    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.
    Greg Comeau, Dec 11, 2004
  8. 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?
    E. Robert Tisdale, Dec 11, 2004
  9. jrefactors

    Sniper1 Guest

    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.
    It is not commonly used, for lack of compiler support in most
    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.
    Sniper1, Dec 11, 2004
  10. jrefactors

    Greg Comeau Guest

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

    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 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.
    Greg Comeau, Dec 11, 2004
  11. jrefactors

    Chris Torek Guest

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

    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

    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.
    Chris Torek, Dec 11, 2004
  12. 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?"
    E. Robert Tisdale, Dec 12, 2004
  13. jrefactors

    Greg Comeau Guest

    Just offering a data point, not advocation per se.
    That's probably so.
    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, Dec 12, 2004
  14. 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.".
    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.
    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.
    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.
    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
    Dave Thompson, Dec 20, 2004
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.