I have found in http://en.wikipedia.org/wiki/C99 that Pelles C has full support for C99.
However I have doubts.
As probably you know, the GCC project has not yet reached full support for C99. The details in which GCC is conforming or not are very well documented. However, I cannot understand what exactly means that Pelles C is fully conforming.
Is it conforming for every computer and operating system?
For example, GCC (under command line option -std=c99) is compliant with ISO/IEC IEEE 60559 (floating point standard) if the hardware is perfectly compliant.
http://gcc.gnu.org/c99status.html
Is Pelles C concerned with this level of detail?
I don't feel sure about the claims that Pelles C is C99 conforming.
According to this article and Wikipedia, Pelles C has full support for C99 (and C11). So unless you have evidence showing that it doesn't, I think one can say it conforms the C99 standard.
As for the support for IEC 60559 floating-point arithmetic, note that it's only optional in C99 (and in C11):
C99 §6.10.8 Predefined macro names
The following macro names are conditionally defined by the implementation:
__STDC_IEC_559__ The integer constant 1, intended to indicate conformance to the
specifications in annex F (IEC 60559 floating-point arithmetic).
__STDC_IEC_559_COMPLEX__ The integer constant 1, intended to indicate adherence to the specifications in informative annex G (IEC 60559 compatible complex arithmetic).
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.
It seems as if __STDC_IEC_559__ is insufficient to test for IEEE-754 compliance within the Apple ecosystem whcih leads to my question:
Which MacOS does support IEEE-754 full or at least the part with the binary32 and binary64 format and how to test for it with one or more C preprocessor macros?
It seems as if __STDC_IEC_559_ is insufficient to test for IEEE-754 compliance within the Apple ecosystem.
Yes and no. For one thing, it depends in part on your compiler, not just OS. For another, you need to be careful how you interpret the compiler's use of that macro.
As a preliminary matter, the __STDC_IEC_559__ macro (note: two trailing underscores) was introduced in C99. There are still compilers out there that do not conform to C99, at least by default. For it to make any sense to test __STD_IEC_559__ at all, then, you should first check whether the compiler claims to conform to C99 or later:
#if __STDC__ && __STDC_VERSION__ >= 19901L
// __STDC_IEC_559__ may tell us something ...
#endif
Supposing that you're working with a conforming implementation, you next need to appreciate that if an implementation defines __STDC_IEC_559__ to 1, it is asserting that it conforms to all the specifications in Annex F (C11) or Annex G (C99) of the standard, which cover not only floating-point data formats but also a fairly wide variety of specifications for operators and functions, including error bounds. The __STDC_IEC_559__ not being defined does not say anything about which part(s) are unsupported. In practice, almost everyone uses ISO 60559 data formats these days, but full ISO 60559 conformance is relatively rare.
Which MacOS does support IEEE-754 full or at least the part with the binary32 and binary64 format and how to test for it with one or more C preprocessor macros?
To the best of my knowledge, all versions of MacOS / OS X running on Intel chips support binary32 and binary64 as native floating-point formats. All the common compilers for those platforms map those native types to C float and double. There is no reliable, standard way to get the C preprocessor test that, however, because no standard macros provide that information, and actual testing would require floating-point math, which the preprocessor does not perform.
The closest you can come to testing the data formats via the preprocessor is to include float.h and examine the macros that define the characteristics of types float and double. But even if these characteristics exactly match those of binary32 / binary64, that does not prove that the actual representations in memory take those forms. If you specifically care about the representation, then you'll need an external test program.
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.
What is the difference between the C version (e.g. C99) and the C compiler version (e.g. 4.9.3)
$ ./arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 227977 with DYNAMIC_REENT by Ambarella]
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
How can I tell whether I am using at least C99 so that I may take advantage of certain macros.
C version is the name of the C standard.
Major standards in historical order:
K&R
ANSI (aka C89 for ANSI, and C90 for ISO)
C99
C11
As the C language has evolved during the last 40 years — new or amended features were introduced in those standards.
gcc compiler version - is just the version of the software. Older versions may not support newer C standards. You can inform the compiler what standard your code conforms to using command line options:
2.1 C Language
The original ANSI C standard (X3.159-1989) was ratified in 1989 and
published in 1990. This standard was ratified as an ISO standard
(ISO/IEC 9899:1990) later in 1990. There were no technical differences
between these publications, although the sections of the ANSI standard
were renumbered and became clauses in the ISO standard. The ANSI
standard, but not the ISO standard, also came with a Rationale
document. This standard, in both its forms, is commonly known as C89,
or occasionally as C90, from the dates of ratification. To select this
standard in GCC, use one of the options -ansi, -std=c90 or
-std=iso9899:1990; to obtain all the diagnostics required by the standard, you should also specify -pedantic (or -pedantic-errors if
you want them to be errors rather than warnings). See Options
Controlling C Dialect.
Errors in the 1990 ISO C standard were corrected in two Technical
Corrigenda published in 1994 and 1996. GCC does not support the
uncorrected version.
An amendment to the 1990 standard was published in 1995. This
amendment added digraphs and __STDC_VERSION__ to the language, but
otherwise concerned the library. This amendment is commonly known as
AMD1; the amended standard is sometimes known as C94 or C95. To select
this standard in GCC, use the option -std=iso9899:199409 (with, as for
other standard versions, -pedantic to receive all required
diagnostics).
A new edition of the ISO C standard was published in 1999 as ISO/IEC
9899:1999, and is commonly known as C99. (While in development, drafts
of this standard version were referred to as C9X.) GCC has
substantially complete support for this standard version; see
http://gcc.gnu.org/c99status.html for details. To select this
standard, use -std=c99 or -std=iso9899:1999.
Errors in the 1999 ISO C standard were corrected in three Technical
Corrigenda published in 2001, 2004 and 2007. GCC does not support the
uncorrected version.
A fourth version of the C standard, known as C11, was published in
2011 as ISO/IEC 9899:2011. (While in development, drafts of this
standard version were referred to as C1X.) GCC has substantially
complete support for this standard, enabled with -std=c11 or
-std=iso9899:2011. A version with corrections integrated is known as C17 and is supported with -std=c17 or -std=iso9899:2017; the
corrections are also applied with -std=c11, and the only difference
between the options is the value of __STDC_VERSION__.
By default, GCC provides some extensions to the C language that, on
rare occasions conflict with the C standard. See Extensions to the C
Language Family. Some features that are part of the C99 standard are
accepted as extensions in C90 mode, and some features that are part of
the C11 standard are accepted as extensions in C90 and C99 modes. Use
of the -std options listed above disables these extensions where they
conflict with the C standard version selected. You may also select an
extended version of the C language explicitly with -std=gnu90 (for C90
with GNU extensions), -std=gnu99 (for C99 with GNU extensions) or
-std=gnu11 (for C11 with GNU extensions).
The default, if no C language dialect options are given, is
-std=gnu11.
The ISO C standard defines (in clause 4) two classes of conforming
implementation. A conforming hosted implementation supports the whole
standard including all the library facilities; a conforming
freestanding implementation is only required to provide certain
library facilities: those in <float.h>, <limits.h>, <stdarg.h>, and
<stddef.h>; since AMD1, also those in <iso646.h>; since C99, also
those in <stdbool.h> and <stdint.h>; and since C11, also those in
<stdalign.h> and <stdnoreturn.h>. In addition, complex types, added in
C99, are not required for freestanding implementations.
The standard also defines two environments for programs: a
freestanding environment, required of all implementations and which
may not have library facilities beyond those required of freestanding
implementations, where the handling of program startup and termination
are implementation-defined; and a hosted environment, which is not
required, in which all the library facilities are provided and startup
is through a function int main (void) or int main (int, char *[]). An
OS kernel is an example of a program running in a freestanding
environment; a program using the facilities of an operating system is
an example of a program running in a hosted environment.
GCC aims towards being usable as a conforming freestanding
implementation, or as the compiler for a conforming hosted
implementation. By default, it acts as the compiler for a hosted
implementation, defining __STDC_HOSTED__ as 1 and presuming that when
the names of ISO C functions are used, they have the semantics defined
in the standard. To make it act as a conforming freestanding
implementation for a freestanding environment, use the option
-ffreestanding; it then defines __STDC_HOSTED__ to 0 and does not make assumptions about the meanings of function names from the standard
library, with exceptions noted below. To build an OS kernel, you may
well still need to make your own arrangements for linking and startup.
See Options Controlling C Dialect.
GCC does not provide the library facilities required only of hosted
implementations, nor yet all the facilities required by C99 of
freestanding implementations on all platforms. To use the facilities
of a hosted environment, you need to find them elsewhere (for example,
in the GNU C library). See Standard Libraries.
Most of the compiler support routines used by GCC are present in
libgcc, but there are a few exceptions. GCC requires the freestanding
environment provide memcpy, memmove, memset and memcmp. Finally, if
__builtin_trap is used, and the target does not implement the trap pattern, then GCC emits a call to abort.
For references to Technical Corrigenda, Rationale documents and
information concerning the history of C that is available online, see
http://gcc.gnu.org/readings.html
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).