I understand that there is both an ANSI standard and an ISO standard for C. Are there any differences between these two standards? If so, what are they? And if there is not a difference then what's the point of having two standards?
In 1990, the ANSI C standard (with a few minor modifications) was adopted by the International Organization for Standardization as ISO/IEC 9899:1990. This version is sometimes called C90. Therefore, the terms "C89" and "C90" refer to essentially the same language.
Source, the situation is similar but reversed for C99. There is also a C FAQ entry on the matter.
The reason that there are two standards is simple: ANSI is a north-american standards body while ISO is an international one.
Aside from the fact that new revisions will be ratified by the ISO before national standards bodies like ANSI, the two are the same. However, common incorrect usage is for "ANSI C" to mean the original language standardized by ANSI in 1989, and "ISO C", "ISO C99", or simply "C99" to mean the current standard adopted by the ISO in 1999.
Related
Recently I've read "Extreme C Programming" book and often heard that
C is a Standard
I know, C is standardized by ANSI. But what does it really mean? Is this is about keywords, supported functions or headers?
It means that there is international standardization in the form of a document ISO/IEC 9899:2018 1) stating how compilers and applications should behave. ISO is an international collaboration, consisting of working groups that take input from national standardization institutes such as ANSI/INCITS in USA. So saying that C is standardized by ANSI is wrong unless you happen to live in USA, where the local name for the standard is INCITS/ISO/IEC 9899:2018.
The whole language is specified in this document: terms, behavior, keywords, operators, environment considerations, certain libraries and so on.
1) The official standard costs money to obtain. For student/hobbyist purposes, you can download a draft version of the standard for free though, such as the C11 draft.
If the sentence indeed refers to C being ANSI/ISO standardized, it refers to a lot of things, including your "keywords, supported functions or headers". The ISO C standard defines:
The preprocessor directives (defines and includes).
The syntax (the grammar, the formal structure): The keywords and other building blocks of the language (literals, operators, identifier syntax) and how these can be combined to expressions and statements in order to form a syntactically correct C program.
The semantics of a program (which grammatically correct constructs are allowed, and what is their meaning).
The C Standard Library (malloc, printf, memcpy etc.). The "user facing" part of that library are the headers (stdio.h, string.h etc.) which name and describe the functions available in the standard library. The "system facing" part of the standard library is the actual compiled code of those functions, typically in the form of library files in a platform specific format with platform specific names in platform specific locations such as libc.a on a gcc/linux system. Because the standard library is so commonly used by normal programs, no special effort must be made to link to it: The linker does that automatically. (You still need to include the proper header file though to let the compiler know about the function names and the arguments you want to use.)
Saying that C is a "standard" can have both meanings: The ISO standardization detailed above, but also the fact that C, compared to assembler, is an abstraction layer that shields a program from peculiarities of the underlying hardware, for example is word length, its endianness, signedness of its character type etc. The interaction with the "system" a program is running on is abstracted through the aptly named "Standard Library".
A well-written C program runs without or with only minor modification on a wide variety of platforms. In this sense C was a de-facto "standard" for programming for years before its formal ISO standardization at the end of the 1980s, much in the sense that *nix in one of its flavors has become a de-facto standard for server operating systems.
Addendum: After browsing the accessible part of the book that inspired your question I can say with confidence that the author indeed addresses both meanings of "standard": He talks about the different ISO C standard versions, dedicating an entire chapter to C 2018; but he also says the following, on "54% of sample" (I cannot see a page number there; emphasis by me):
The size of a pointer depends on the architecture rather than being a specific C concept. C doesn't worry too much about such hardware-related details, and it tries to provide a generic way of working with pointers and other programming concepts. That is why we know C as a standard.
I know, C is standardized by ANSI
C was standardized by ANSI in 1989 (aka C89).
It was then globally adopted by ISO/IEC JTC1/SC22 Programming Languages in 1990 as ISO/IEC 9899:1990 (aka C90).
Working Group 14 (WG14) of SC22 have subsequently evolved the C Standard as:
ISO/IEC 9899:1990 (aka C90)
ISO/IEC 9899:1990/AMD1:1995 (aka C95)
ISO/IEC 9899:1999 (aka C99)
ISO/IEC 9899:2011 (aka C11)
ISO/IEC 9899:2018 (aka C18 - although sometimes called C17 as __STDC__ is 201710L)
ISO/IEC 9899:202x (aka C2x) is pending...
There were a couple of TCs too...
As a Standard it has requirements for conformance.
I'm a little confused by "C standard lib" and "C POSIX lib", because I found that, many header files defined in "C POSIX lib" are also part of "C standard lib".
So, I assume that, "C standard lib" is a lib defined by ANSI C organization, and there are different implementation on different platforms (Win32/Unix-like), and "C POSIX lib" is just a implementation for "C standard lib" on Unix-like OSes, right?
But "C POSIX lib" contains some headers not specified in "C standard lib", such as <sys/types.h>, <sys/wait.h>, and <pthread.h>.
Take <pthread.h> as an example, I presume its "C standard lib" counterpart is <threads.h>, then if I want to write a multi-threaded program on Linux, which header file should I include, <pthread.h> or <threads.h>?
POSIX is a superset of the standard C library, and it's important to note that it defers to it. If C and POSIX is ever in conflict, C wins.
Sockets, file descriptors, shared memory etc. are all part of POSIX, but do not exist in the C library.
pthread.h is used for POSIX threads and threads.h is a new header for C11 and is part of the C library. Perhaps pthreads will be deprecated sometime in the future in favor of the C ones, however you probably can't count on C11 to have widespread deployment yet. Therefore if you want portability you should prefer pthreads for now. If portability is not a concern, and you have C11 threads available, you should probably use those.
The C POSIX library is a specification of a C standard library for POSIX systems. It was developed at the same time as the ANSI C standard. Some effort was made to make POSIX compatible with standard C; POSIX includes additional functions to those introduced in standard C.
POSIX 7 quote
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap01.html#tag_14_01
1.1 Relationship to Other Formal Standards
Great care has been taken to ensure that this volume of POSIX.1-2008 is fully aligned with the following standards:
ISO C (1999)
ISO/IEC 9899:1999, Programming Languages - C, including ISO/IEC 9899:1999/Cor.1:2001(E), ISO/IEC 9899:1999/Cor.2:2004(E), and ISO/IEC 9899:1999/Cor.3.
Parts of the ISO/IEC 9899:1999 standard (hereinafter referred to as the ISO C standard) are referenced to describe requirements also mandated by this volume of POSIX.1-2008. Some functions and headers included within this volume of POSIX.1-2008 have a version in the ISO C standard; in this case CX markings are added as appropriate to show where the ISO C standard has been extended (see Codes). Any conflict between this volume of POSIX.1-2008 and the ISO C standard is unintentional.
I have listed some major API extensions at: I never really understood: what is POSIX?
ANSI C is still alive, I think: ANSI C is inherited and extended by ISO C, Cxx. POSIX have been obeying ANSI C absolutely."
We can write ANSI C on Windows, Unix-Like, embedded device easily; but Cxx, or POSIX may have issue.
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.
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.
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.
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
This question was not thoroughly searched on net for answer ,anyway you may look at this :
C is a general-purpose programming language initially developed by
Dennis Ritchie between 1969 and 1973 at AT&T Bell Labs.
C99 is a standard of the C language published by ISO and adopted by ANSI in around 1999.
GNU C is just an extension of c89,while some features of c99 are also added,but in entirety it is different from c99 standard so when compiling in gcc we have to enter -std=c99 which is already mentioned in the other answers.
ANSI C is a successive series of standards released by ANSI.
This question already has answers here:
Where do I find the current C or C++ standard documents?
(11 answers)
Closed 3 years ago.
I am in the situation where I may have the opportunity to teach C to some students. The University wants to teach them pure c, not c++, to keep the advanced c++ course separate.
Since c++ is derived from c, is there an official "c rulebook" which contains all the features of c, but none of the c++ features? The reason I want to know is so I can look up what I need to teach the students.
I once saw a (2000 page?) manual on the c++ standard. Does such a thing exist for c, even if it is 20/30 years old by now?
Regards,
Ed
EDIT: I should point out I know C/C++ quite well having been teaching myself for 3 years. The only thing I don't know is what things are "officially" C and what things are "officially" C++. This is what I aim to learn so I can give the other students a better education than I could give myself.
There have been 3 official ISO C standards, published in 1990, 1999, and 2011. There have also been several "Technical Corrigenda", official documents making corrections to the standards.
The standard itself can be purchased in PDF (or paper) format from ISO or from your national standards body, such as the US ANSI. ANSI sells the C11 standard for about $30, but with strict licensing requirements. The Technical Corrigenda are available by themselves at no charge, but they're not useful without the standard. If you want to make the standard available to your class, that's probably not a practical way to do it.
But drafts of the C standards are often made available on the ISO C committee's site.
N1256 is a draft of the C99 standard with the three Technical Corrigenda merged into it. It's actually better for most purposes than the official C99 standard.
N1570 is the most recent (as far as I know, as I write this) draft of the 2011 ISO C standard, published before the ISO standard was released. There are only a few minor editorial differences between N1570 and the official standard.
There's also a small Technical Corrigendum to the C11 standard, containing a couple of fixes that aren't in either N1570 or C11: due to an oversight, the published standard didn't define the value of __STDC_VERSION__ and the optional __STDC_LIB_EXT1__ macros properly (both are 201112L).
Each standard (and draft) has a summary of the differences between it and the previous standard.
Apart from the standard (which is not really written for general programmers), Harbison & Steele's C: A Reference Manual is a very good reference. The current 5th edition covers C90 and C99, but not C11. (I don't know of any plans for a 6th edition.)
You're looking for a C standard. Since the standards bodies fund themselves through the sale of standard publications, you can't get the final version. However, there are many copies of C draft standards out there which are good enough for your purposes.
https://www.google.com/search?q=c+draft+standard+pdf
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
In Xcode IDE, I have an option to set C language dialect one of
ANSI C
GNU89
C89
GNU99
C99
Compiler Default
I understand what they mean except ANSI C. Because As I know, ANSI C is just one of C89 or C99. But there should be a reason about it's on there. What's the term ANSI C specifies in there?
edit Credit goes to #Nicholas Knight for posting a screenshot from XCode's C dialect selection window: http://dl.dropbox.com/u/14571816/xcodelang.png
ANSI C refers, historically, to the ANSI C89 standard (practically the same thing as C90). XCode uses a version of GCC as the compiler back-end for compiling C code, so I think that's where they get these 'options' from, as you can specify the -ansi flag or various std= flags to choose the mode the C compiler backend should operate in for compiling your code.
So if you pass it -ansi, and using the C compiler, it's equivalent to -std=c90, which is also equivalent to -std=c89 or -std=iso9899:1990.
-ansi
In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to
-std=c++98.
And if you use the -std flags, you can pass certain values to activate different language features.
-std=
Determine the language standard. This option is currently only supported when compiling C or C++.
These arguments are equivalent:
c90
c89
iso9899:1990
Support all ISO C90 programs (certain GNU extensions that conflict with ISO C90 are disabled). Same as -ansi for C code.
These arguments are equivalent:
iso9899:199409
ISO C90 as modified in amendment 1.
These following arguments are equivalent:
c99
c9x
iso9899:1999
iso9899:199x
ISO C99. Note that this standard is not yet fully supported; see
http://gcc.gnu.org/gcc-4.5/c99status.html for more information. The names c9x
and iso9899:199x are deprecated.
These following arguments are equivalent:
gnu90
gnu89
GNU dialect of ISO C90 (including some C99 features). This is the default for C
code.
These following arguments are equivalent:
gnu99
gnu9x
GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC, this will
become the default. The name gnu9x is deprecated.
Compilers have profiles of the languages they are targeting, like pmg said in his reply ANSI C was one of the earliest profiles, the one that is described in the K&R book.
The question of interest is, why do compilers maintain a list of legacy language profiles ? Because, writing code against the ANSI C profile is quite a strong guarantee that your code will work with virtually any compiler (more importantly compiler version).
When software projects claim ANSI-C compatibility they are telling you that it will compile everywhere give-or-take. Lua's source code is an example of this.
C was "born" in the 70's.
In 1978 Brian Kernighan and Dennis Ritchie published the book. The language as described in the book (the 1st edition) is now called "K&R C".
In 1988 or so, there was a 2nd edition published. This 2nd edition is very, very similar to the ANSI (ISO) Standard, and is the edition that people talk about usually when referring to the book :)
Compiler writers started to make changes to the language and, in order to standardize it, ANSI published a Standard in 1989 (The C89 Standard or ANSI C). This was shortly followed by the ISO standard (C90) which makes hardly any changes to the ANSI.
In 1999, ISO published another C Standard: What we call C99.
So, if I'm right, ANSI C was current only for a few months, but the difference between ANSI C and ISO C90 is minimal. In fact, many compilers today are compilers for ANSI C with extras (rather than for ISO C99 with extras but without a few things)
Assuming you are, in fact, using GCC as the compiler, ANSI and C89 are aliases for the same thing. See:
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
Why Apple made the design decision to present them both, I'm not sure. There is no practical distinction in GCC. Perhaps they're being paranoid in case the meaning of -ansi changes in later versions of GCC (perhaps to C99).