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.
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 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've started working with Turbo C 2.01 as a hobby project. Yes, the DOS version. Since it came out in 1987, I assume it doesn't support C90... except it does. Well, pieces of it. The volatile keyword works. And straight K&R isn't supported; I tried K&R style declarations, to an error.
So, I was wondering what form of C Turbo C uses. I'm sure it's nonstandard, but it seems somewhat consistent, and since this was a very popular compiler back in the day, I'm sure there's some collection of information... right?
There was no real standard back then, and additionally MS-DOS had its own quirks (namely the segmented memory model, and different application memory models using them differently...).
So I think it's safe to say, Turbo C 2.01 uses Turbo C 2.01 dialect of C.
About supporting C90, note that the standard obviously did its best to have existing C code be compatible with it. So it's not surprising Turbo C from 87 can build most C90 programs with minimal changes.
According to wikipedia, original K&R non standard spec came out in 78. The starting point of the ANSI X3J11 committee that produced the ANSI C89 standard is 1983, and the goal was
to establish a standard specification of C. X3J11 based the C standard on the Unix implementation.
That standard was then adopted by ISO as C90. But as it was extensively based on an existing implementation, the extensions from this implementation were already ported in other implementations like Borland's one.
So there is no real suprise that Borland C2.01 from 87 already includes most of the extensions to K&R C that has been adopted in standard only 2 years later.
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).