Status of C99 features in GCC

This table is based on the list in the foreword to the printed standard ISO/IEC 9899:1999 (E), as amended by ISO/IEC 9899:1999/Cor.1:2001 (E) and ISO/IEC 9899:1999/Cor.2:2004 (E).

Where "Library Issue" is listed in conjunction with some other status, this means that some compiler support is needed for the library support, or desirable in conjunction with it. Note that the headers required of conforming freestanding implementations (clause 4 paragraph 6) do not count as library issues.

This page describes the C99 support in mainline GCC, not in any particular release. Information is also available on C99 support in GCC 4.1, C99 support in GCC 4.0, C99 support in GCC 3.4, C99 support in GCC 3.3, C99 support in GCC 3.1 and 3.2 and on C99 support in GCC 3.0, but not on the much more limited support in GCC 2.95.

See below the table for further notes on some issues.

Feature	Library Issue	Done	Broken	Missing
restricted character set support via digraphs and `<iso646.h>` (originally specified in AMD1)		Done
wide character library support in `<wchar.h>` and `<wctype.h>` (originally specified in AMD1)	Library Issue			Missing
more precise aliasing rules via effective type		Done
restricted pointers		Done
variable-length arrays			Broken
flexible array members		Done
`static` and type qualifiers in parameter array declarators		Done
complex (and imaginary) support in `<complex.h>`			Broken
type-generic math macros in `<tgmath.h>`	Library Issue	Done
the `long long int` type and library functions		Done
increased minimum translation limits		Done
additional floating-point characteristics in `<float.h>`		Done
remove implicit `int`		Done
reliable integer division		Done
universal character names (`\u` and `\U`)		Done
extended identifiers				Missing
hexadecimal floating-point constants and `%a` and `%A` `printf`/`scanf` conversion specifiers	Library Issue	Done
compound literals		Done
designated initializers		Done
`//` comments		Done
library functions in `<inttypes.h>`	Library Issue
extended integer types in `<stdint.h>`				Missing
remove implicit function declaration		Done
preprocessor arithmetic done in `intmax_t`/`uintmax_t`		Done
mixed declarations and code		Done
new block scopes for selection and iteration statements		Done
integer constant type rules		Done
integer promotion rules		Done
macros with a variable number of arguments		Done
the `vscanf` family of functions in `<stdio.h>` and `<wchar.h>`	Library Issue	Done
additional math library functions in `<math.h>`	Library Issue			Missing
floating-point environment access in `<fenv.h>`	Library Issue
IEC 60559 (also known as IEC 559 or IEEE arithmetic) support			Broken
trailing comma allowed in `enum` declaration		Done
`%lf` conversion specifier allowed in `printf`	Library Issue	Done
inline functions			Broken
the `snprintf` family of functions in `<stdio.h>`	Library Issue	Done
boolean type in `<stdbool.h>`		Done
idempotent type qualifiers		Done
empty macro arguments		Done
new struct type compatibility rules (tag compatibility)		Done
additional predefined macro names				Missing
`_Pragma` preprocessing operator		Done
standard pragmas				Missing
`__func__` predefined identifier		Done
`va_copy` macro		Done
additional `strftime` conversion specifiers	Library Issue	Done
deprecate `ungetc` at the beginning of a binary file	Library Issue
remove deprecation of aliased array parameters		Done
conversion of array to pointer not limited to lvalues		Done
relaxed constraints on aggregate and union initialization		Done
relaxed restrictions on portable header names		Done
`return` without expression not permitted in function that returns a value (and vice versa)		Done
Feature	Library Issue	Done	Broken	Missing

Further notes

cpp has limited support for multibyte character sets.
IEC 60559 is IEEE 754 floating point. This works if and only if the hardware is perfectly compliant, but GCC does not define __STDC_IEC_559__ or implement the associated standard pragmas.
Compiler support is needed for math_errhandling; see messages 1, 2, 3 on this subject to libc-hacker.
In some places, -pedantic warnings don't take proper account of the standard version selected.
GCC doesn't have wprintf, wscanf and wcsftime format checking support.
Complex numbers support may be broken (some problems with passing/returning complex values on 64-bit targets, and not checked against the requirements of the C99 standard). However, the _Complex keyword now works.
C99 inline functions do not generate an external definition if declared without extern, but do if declared with extern, the opposite of GCC's handling of inline and extern inline. This will probably require existing glibc headers to be fixincluded.
The C99 semantics of variable length arrays (VLAs) are not fully implemented by the existing GCC extension: the concept of variably modified (VM) types, and the rules for what identifiers can be declared with VLA or VM types, are not implemented (for example, GCC allows elements of VM type in a structure with block scope); while the syntax for arrays to be declared with [*] in parameter declarations is present, the semantics are not; and in general the implementation of VLAs has not been checked against C99 requirements.
const-qualified compound literals could share storage with each other and with string literals, but currently don't.
The information provided by static in parameter array declarators is not used for optimization. It might make sense to use it in future in conjunction with work on prefetching.
The list above differs from that in the C99 standard (as amended by TC1) as follows: "LIA compatibility annex" is removed, since it refers to C99's conformance to another standard rather than something for C implementations to do. The <stdint.h> and <inttypes.h> entries have been separated, but are a single entry in C99.

Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

These pages are maintained by the GCC team.

For questions related to the use of GCC, please consult these web pages and the GCC manuals. If that fails, the gcc-help@gcc.gnu.org mailing list might help.
Please send comments on these web pages and the development of GCC to our developer mailing list at gcc@gnu.org or gcc@gcc.gnu.org. All of our lists have public archives.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Last modified 2006-06-21