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

Question

I have started programming practice on codechef and have been confused by the difference between C and C99. What does C mean here? Is it C89? Check the languages at the bottom of this submit. It contains both C and C99.

I found on the internet something called GNU C. Is there a different C for linux/unix systems? Are these compliant to the C standards by ANSI? I have also read in some places "C99 strict". What is this?

Are there any other different standards of C in use? Is there something called C 4.3.2 or is it the gcc version in current use?

EDIT:

This, This, This helped. I'll search more and edit the things that are left unanswered.

I am not a programming newbie. I know what C language is. I know that there are the different C standards by ANSI like C89, C99 and C11.

Solution 1

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

Solution 2

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.

Solution 3

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

Solution 4

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

View more solutions

Comments

[pmg]

Don't forget about POSIX C :-)

[Aseem Bansal]

I searched on net now. I edited the question. I knew about C and ANSI standards before posting the question. I am having confusion regarding specific things. I'll try to be more precise.

[Aseem Bansal]

Anything about C99 strict and whether the C in codechef is C89 or the earlier non-standardized original C

[Aseem Bansal]

Anything about C99 strict and whether the C in codechef is C89 or the earlier non-standardized original C

[Lundin]

Correction: ANSI C is an obsolete standard, which is only referred to by out-of-date documents. The C language is called ISO C, or if you will ISO/IEC 9899:2011.

[Lundin]

This answer contains many errors. C99 is a standard defined by ISO around 1999. The C language has been internationally standardized for 23 years. Thus ANSI has nothing to do with it, they haven't touched a C standard in 24 years. Nowadays they merely print and distribute the ISO standard for the American market.

[Eric Postpischil]

The strict compiler setting may mean “Disable extensions; use only the C language defined by the standard” as well as, or more than, “compile correctly”. It is completely correct to accept extensions to the language; the standard was defined to allow that.

[0decimal0]

@Lundin Oh!! yeah , actually i wrote "defined" which is not the case,it should be "adopted" there.i made the correction,ANSI released the very first standard for C way back in 1989 which was adopted by ISO.after that almost all standards were released by ISO and adopted by ANSI, and the answer is brief as being asked,so i just mentioned few things keeping the answer short.

[Jonathan Leffler]

There was also the C94/C95 Amendment 1 that added more wide character support, mainly. See also List of Standard Header Files in C and C++.

[Jonathan Leffler]

Note that gcc supports -std=c89 and -std=gnu89 and -std=c99 and -std=gnu99 (and modern enough versions support -std=c11 and -std=gnu11). The difference is to do with extensions over the Standard C being available automatically or only when the source prods the compiler into providing them with appropriate macros (such as -D_XOPEN_SOURCE=700).

[Martin Thoma]

You write that lots of things changed from C90 to C99. Could you please name a few?

[Lundin]

@moose open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf page 9 in the pdf.

[Antti Haapala -- Слава Україні]

@Lundin you linked the wrong book for K&R; this is the second edition that describes the C89 standard.

[Lundin]

@AnttiHaapala Nobody would ever want to read the 1st edition though... I wouldn't want to link to it or some confused person is going to purchase it and read it. The 2nd edition is harmful enough reading without mixing in the 1st one.

[Antti Haapala -- Слава Україні]

Yeah, but the point is that that is not the version which defined the C programming language up to the point; not that it would be on sale anywhere.

[supercat]

Too bad Dennis Ritchie didn't realize how aliasing rules would be used to imply that compilers shouldn't make any effort to recognize useful forms of aliasing, but instead argue that programmers whose code is broken by obtuse compilers should "thank" the compilers for showing them their code is "defective"--otherwise he could have told the people pushing such rules to make clear that refusal to support aliasing beyond the Standard's minimal requirements will make compilers unsuitable for some purposes, and low-level code's need for aliasing is not a defect.

[Suraj Jain]

@supercat I actually did not understand what aliasing rules means can you help me out?

[supercat]

The original concept was that given code like int i; int test(double *p) { i=1; *p=2.0; return i; } a compiler shouldn't be required to reload i after the write to *p on the off chance that p might hold the address of i. Perfectly reasonable. The problem is that modern compilers use the same rule to justify assumptions that writes to a long* won't affect a long long, even if both types have the same size and representation, and that even if two structures share a Common Initial Sequence, code will never use a pointer of one type to read a CIS member written via the other.

[supercat]

Further, if one is doing maintenance on an embedded project which was built using a twenty-year-old compiler, it's often better to continue using the twenty-year-old compiler than to use a more recent version, even if upgrades are available, unless serious bugs have been found in the old version of the compiler and fixed in later ones.

[supercat]

If a compiler vendor switches from using a proprietary compiler design to one based on clang, and only the clang-based one supports C11 features, that would be a strong argument in favor of limiting oneself to features that were supported by the robust older compiler rather than the more "modern" one.