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.
Related
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.
Why not all the standard headers are preceded with std prefix? I.e. why complex.h and not stdcomplex.h?
Why? why not? Who knows? The header files that make up the standard libraries began evolving into that category before a standard existed, over years of revisions by developers and scrutiny by C committee members. Many of the original authors and committee members who developed and canonized these files are now part of the big compiler in the sky and not available to answer the question "why" the standard naming convention is not really conventional or standard. But reading this wiki page on the topic may at least allow you to get a little history and context.
The naming has historically nothing to do with formal ISO standardization and I don't think there ever was an ambition to toss std in front of everything standard library.
Earliest mention of a standard library seems to be K&R The C programming Language 1st edition from 1978, where below chapter 8.5 we can read:
The data structure that describes a file is contained in the file stdio.h, which must be included (by #include) in any source file that uses routines from the standard library.
Notably K&R refers to it as the standard library, not the standard input/output library. So maybe (and this is speculation) this header was originally intended to be the whole standard library for C. This is the only one of the current ISO standard library headers I can find mentioned in the book and it pre-dates formal standardization by more than ten years.
Then later during ANSI/ISO standardization the headers stdarg, stddef, stdio and stdlib were added to the first standard, but these are just 4 out of 15 standard headers using the std prefix. Various C or Unix de-facto standard headers just got added to the standard pretty much arbitrary. There was no sound rationale for anything, least of all API or naming. They just tossed in various already present "good to have" Unix libs into the standard.
Notably, the original C standard only guaranteed 6 unique letters for standard headers and all the original headers have names with 6 or less letters. This was expanded to 8 letters in C99.
C99 continued the tradition of arbitrary naming, adding a whole bunch of new headers, of which only stdint and stdbool have the std prefix. That C11 named most new headers with std prefix might be some influence from C++, but notably C11 also added uchar.h without prefix.
I just tried to compile a C program with a GNU compiler version 4.9.2. The source code contained a few for int i=0; ... statements and the compiler gave me an error and indicated that I should use -std=c99 in order to compile for loop initial declarations. Apparently, such declarations were not valid before C99.
On an another machine, I have a more recent GNU compiler (8.1.1) where I can compile the same source code without explicitly specifying -std=c99.
Because GNU obviously made their compiler C99 compliant between 4.9.2 and 8.1.1, this lead me to the question if a recent C standard specified that a compiler has to adhere to C99 (or another standard).
Choosing whether to adhere to the C standard, or a particular version of it, is voluntary. The choice does not come from the C standard. It comes from outside. Anybody who makes a C implementation decides whether to conform to the 2018 C standard (or to conform mostly but not completely), whether to conform to the 2011 C standard, whether to conform to some “K&R” notion of C, or something else. Nothing in the C standard says, well, if you are conforming to this standard, your compiler has to conform to some previous version. The standard cannot actually require you to do anything until you choose to conform to the standard.
The C standard and the people who make it and the standards organizations that endorse and publish it have little power to make anybody do anything. They cannot publish the C standard and say you, René Nyffenegger, must obey the 2018 C standard. They are not law-making bodies. There are contracts between private parties which say some project will be produced in accordance to this standard or that standard, but those are private agreements, not public law.
In the 2018 C standard, paragraph 8 of the Foreword says:
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see the following URL: www.iso.org/iso/foreword.html.
Nor can the standard organizations prohibit you from writing a C compiler that does or does not conform to any particular version of the standard, nor from writing a compiler that conforms largely but not completely.
If you use the name of the C standard commercially, perhaps by claiming conformance to it, the standards organizations might have some legal rights in that regard. That involves international law and the law of many jurisdictions, which I cannot speak to authoritatively. I have not heard of any problems occurring from somebody claiming to conform to the C standard.
The standards organizations do officially withdraw old versions of the standards when a new version is published. This does not prevent you from writing a C implementation that conforms to an old version, but it would prevent you from claiming you are conforming to the current version when you are not. (For example, if a contract you agreed to required you to conform to the current C standard, that would change when the organization publishes a new version and withdraws the old one.)
Prior to GCC 5.0, the default standard it adhered (most closely) to was the C90 standard — specifying no standard was equivalent to specifying -std=gnu90.
From 5.0 onwards, the default was changed to the C11 standard — so specifying no standard was equivalent to specifying -std=gnu11.
Your two compiler versions show this behaviour.
Note that the C standard only prescribes what a compiler must do to adhere to that standard. It does not mandate the behaviour of a compiler with respect to previous or future versions of the standard; there is only one version of the standard as far as the standard is concerned. What compiler implementations do about other versions is entirely up to the compiler writers.
You can, of course, override the default behaviour of GCC with an explicit version:
-ansi
-std=c90
-std=c99
-std=c11
-std=gnu90
-std=gnu99
-std=gnu11
… and some other variations …
The -ansi option is equivalent to -std=c90. The difference between the -std=cXX and -std=gnuXX is that the c version doesn't set the macros for various extensions, so you might have to explicitly indicate that you want to use POSIX interfaces, for example, with options such as -D_XOPEN_SOURCE=700, whereas with gnu version sets those macros automatically.
The each version of the C Standard classifies implementations into two categories: those which comply with that particular version of the Standard, and those that don't. There aren't any C Language Police who will break the kneecaps of anyone who sells non-conforming implementation. Indeed, there are some situations where a non-conforming implementation would be more useful than any conforming implementation could be (e.g. on some small embedded platforms, the amount of code required to produce a full conforming implementation of "printf" might exceed the total code space available). Further, there is no guarantee that a every conforming implementation will be suitable for any particular purpose (indeed, it would be possible to contrive a C implementation which was unsuitable for any purpose whatsoever except to demonstrate that the C Standard doesn't mandate usefulness).
Most quality C development systems can be invoked in different modes which may conform (or fail to conform) with different versions of the Standard, and may be suitable (or unsuitable) for various purposes. From the point of view of the Standard, every different mode in which a development system can be invoked would be a different implementation. I think it would be useful to have the Standard to sub-categorize implementations based upon their support (or lack thereof) for popular features or guarantees that would make them suitable (or unsuitable) for common purposes (e.g. low-level or systems programming) but as yet the Standard has not done so.
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.
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.