What is the difference between C, C99, ANSI C and GNU C?

• ANSI C : The first C language was standardized by the body called ANSI in 1989 that's why it is called c89.

• C99 :
  with the demand from the developers requirements, in 1999-2000 further or additional keywords and features have been included in C99 (ex: inline, boolean.. Added floating point arthematic library functions)

• GNU C: GNU is a unix like operating system (www.gnu.org) & somewhere GNU's project needs C programming language based on ANSI C standard. GNU use GCC (GNU Compiler Collection) compiler to compile the code. It has C library function which defines system calls such as malloc, calloc, exit...etc

ANSI C is a standard which is being used by or refereed the other standards.

• Everything before standardization is generally called "K&R C", after the famous book (1st edition and 2nd edition), with Dennis Ritchie, the inventor of the C language, as one of the authors. This was "the C language" from 1972-1989.

• The first C standard was released 1989 nationally in USA, by their national standard institute ANSI. This release is called C89 or ANSI-C. From 1989-1990 this was "the C language".

• The year after, the American standard was accepted internationally and published by ISO (ISO 9899:1990). This release is called C90. Technically, it is the same standard as C89/ANSI-C. Formally, it replaced C89/ANSI-C, making them obsolete. From 1990-1999, C90 was "the C language".

  Please note that since 1989, ANSI haven't had anything to do with the C language, other than as one of many instances working on the ISO standard. It is nowadays done in USA through INCITS and the C standard is formally called INCITS/ISO/IEC 9899 in USA. Just as it is for example called EN/ISO/IEC in Europe.

  Programmers still speaking about "ANSI C" generally haven't got a clue about what it means. ISO "owns" the C language, through the standard ISO 9899.

• A minor update was released in 1995, sometimes referred to as "C95". This was not a major revision, but rather a technical amendment formally named ISO/IEC 9899:1990/Amd.1:1995. The main change was introduction of wide character support.

• In 1999, the C standard went through a major revision (ISO 9899:1999). This version of the standard is called C99. From 1999-2011, this was "the C language".

• In 2011, the C standard was changed again (ISO 9899:2011). This version is called C11. Various new features like _Generic, _Static_assert and thread support were added to the language. The update had a lot of focus on multi-core, multi-processing and expression sequencing. From 2011-2017, this was "the C language".

• In 2017, C11 was revised and various defect reports were solved. This standard is informally called C17 or C18. It was finished in 2017 (and uses __STDC_VERSION__ = 201710L) but was released by ISO as 9899:2018, hence the ambiguity between C17/C18. It contains no new features, just corrections. It is the current version of the C language.

• A draft called "C23"/"C2X" is work in progress by the committee, planned to be released in 2023. The current working draft can be found here, at this point called N2731, last changed 2021-10-18.

  This contains a lot of minor defect report fixes like C17/C18 but also some major changes, most notable (so far):

  • the removal of exotic signedness representations in favour of mandatory 2's complement
  • final removal of "K&R-style" function definitions (flagged obsolescent since C99)
  • some new functions added including memccpy and strdup
  • some new function attributes from C++ deprecated, fallthrough, maybe_unused, and nodiscard
  • binary 0b notation for integer constants (currently not listed as one of the changes to N2731 but present on p.51 of the draft).

---

"C99 strict" likely refers to a compiler setting forcing a compiler to follow the standard by the letter. There is a term conforming implementation in the C standard. Essentially it means: "this compiler actually implements the C language correctly". Programs that implement the C language correctly are formally called strictly conforming programs. Such programs may also not contain any form of poorly-defined behavior.

"GNU C" can mean two things. Either the C compiler itself that comes as part of the GNU Compiler Collection (GCC). Or it can mean the non-standard default setup that the GCC C compiler uses. If you compile with gcc program.c then you don't compile according to the C standard, but rather a non-standard GNU setup, which may be referred to as "GNU C". For example, the whole Linux kernel is made in non-standard GNU C, and not in standard C.

If you want to compile your programs according to the C standard, you should type gcc -std=c99 -pedantic-errors. Replace c99 with c17 if your GCC version supports it.

I MUST respond regarding ANSI C. Although ANSI has not done anything with it, compilers are still built to it. PIC XC16 compiler for example: "The compiler is a fully validated compiler that conforms to the ANSI C standard as defined by the ANSI specification (ANSI x3.159-1989) and described in Kernighan and Ritchie’s The C Programming Language (second edition). ..." Not all programming is for "big" computers like PCs. Writing a compiler for your device costs, and validating costs time & $. ANSI C is alive & well & living in your embedded / real-time devices.

In Addition To Lundin Answer

Here is What Dennis Richie Has To Say When Asked

"Why didn't K&R wait for the final, approved ANSI standard before writing K&R 2nd edition?"

Why didn't K&R wait for the final, approved ANSI standard before writing K&R 2nd edition? It seems like this book will only be the correct standard for a few months before it will be supesceded by the final ANSI standard. I know that there are likely to be few major changes at this late stage, but why not wait a few months and make sure you get it 100% right, rather than needing to almost immediately write a 3rd edition or be obsolete?

We thought it would be nice to mark the 10th anniversary of the first edition. More seriously, we started work last summer because we had the time and inclination then, and it appeared that X3J11 was approaching an end. In December and January, as we were finishing, we considered whether the possibility of important changes warranted putting off delivery, and (after discussing the matter with the publisher) decided that it was not worth waiting. P-H wanted it, and both Brian and I wanted it off our agendas.

Even if there are changes in the standard, it's hard to imagine that they would be extensive enough to warrant a new edition. (We were even prepared to cope somehow with noalias, if it had lasted.) We're ready to make necessary changes in a future printing, but there's reason to hope that they should be minor. X3J11's members are very anxious to finish without surprising people, too; many of them work for companies that are preparing ANSI compilers, after all.

Dennis Ritchie