C99

This article is about the programming language dialect. For other uses, see C99 (disambiguation).

Cover of the C99 standards document

C99 is an informal name for ISO/IEC 9899:1999, a past version of the C programming language standard. It extends the previous version (C90) with new linguistic and library features, and helps implementations make better use of available computer hardware, such as IEEE 754 arithmetic, and compiler technology.

History

After ANSI produced the official standard for the C programming language in 1989, which became an international standard in 1990, the C language specification remained relatively static for some time, while C++ continued to evolve, largely during its own standardization effort. Normative Amendment 1 created a new standard for C in 1995, but only to correct some details of the 1989 standard and to add more extensive support for international character sets. The standard underwent further revision in the late 1990s, leading to the publication of ISO/IEC 9899:1999 in 1999, which was adopted as an ANSI standard in May 2000. The language defined by that version of the standard is commonly referred to as "C99." The international C standard is maintained by the working group ISO/IEC JTC1/SC22/WG14.

Design

C99 is, for the most part, backward compatible with C89 but is stricter in some ways.

In particular, a declaration that lacks a type specifier no longer has int implicitly assumed. The C standards committee decided that it was of more value for compilers to diagnose inadvertent omission of the type specifier than to silently process legacy code that relied on implicit int. In practice, compilers are likely to display a warning, then assume int and continue translating the program.

C99 introduced several new features, many of which had already been implemented as extensions in several compilers:

• inline functions
• intermingled declarations and code: variable declaration is no longer restricted to file scope or the start of a compound statement (block), as in C++
• several new data types, including long long int, optional extended integer types, an explicit boolean data type, and a complex type to represent complex numbers
• variable-length arrays
• support for one-line comments beginning with //, as in BCPL or C++
• new library functions, such as snprintf
• new header files, such as stdbool.h, complex.h, tgmath.h, and inttypes.h
• type-generic math functions
• improved support for IEEE floating point
• designated initializers
• compound literals
• support for variadic macros (macros with a variable number of arguments)
• restrict qualification allows more aggressive code optimization
• universal character names, which allows user variables to contain other characters than the standard character set

Parts of the C99 standard are included in the current version of the C++ standard, C++11, including integer types, header files, and library functions. Variable-length arrays are not among these included parts because C++'s Standard Template Library already includes similar functionality.

IEEE 754 floating point support

A major feature of C99 is its numerics support, and in particular its support for access to the features of IEEE 754 (also known as IEC 60559) floating point hardware present in the vast majority of modern processors (defined in "Annex F IEC 60559 floating-point arithmetic").

On hardware with IEEE 754 floating point:

• float is defined as IEEE 754 single precision, double is defines as double precision, and long double is defined as IEEE 754 extended precision or quad precision where available (e.g. Intel 80 bit double extended precision on x86 or x64 platforms).
• arithmetic operations and functions are correctly rounded as defined by IEEE 754.
• precision of expression evaluation is defined to be performed in one three well-defined methods: FLT_EVAL_METHOD == 2 indicates that all internal intermediate computations are performed by default at high precision (long double) where available (e.g. 80 bit double extended); FLT_EVAL_METHOD == 0 specifies each operation is evaluated only at the precision of the widest operand of each operator; FLT_EVAL_METHOD == 1 performs all internal intermediate expressions in double precision (unless an operand is long double). The intermediate result type for operands of a given precision are summarized in the following table:

FLT_EVAL_METHOD	float	double	long double
0	float	double	long double
1	double	double	long double
2	long double	long double	long double

FLT_EVAL_METHOD == 2 is the safest default as it limits the risk of rounding errors affecting numerically unstable expressions (see IEEE 754 design rationale) and is the designed default method for x87 hardware; FLT_EVAL_METHOD == 1 was the default evaluation method used in K&R C; and FLT_EVAL_METHOD == 0 is also commonly used and specifies a strict "evaluate to type" of the operands. (For gcc, FLT_EVAL_METHOD == 2 is the default on 32 bit x86, and FLT_EVAL_METHOD == 0 is the default on 64 bit x64, but FLT_EVAL_METHOD == 2 can be specified on x64 with option -mno-sse). Note that prior to the precision of intermediate values being precisely specified in C99, C compilers would round intermediate results inconsistently, especially when using x87 floating point hardware, leading to compiler-specific behaviour : such inconsistencies are not permitted in compilers conforming to C99 (annex F).

The following annotated example C99 code for computing a continued fraction function demonstrates the main features:

// compile with: gcc -std=c99 -o test_c99_fp -lm test_c99_fp.c
#include <stdio.h>
#include <math.h>
#include <fenv.h>
#include <tgmath.h>
#include <stdbool.h>
 
double compute_fn(double z)
{
        #pragma STDC FENV_ACCESS ON  // [1]
 
        assert( FLT_EVAL_METHOD == 2 ); // [2]
 
        if (isnan(z)) printf("z is not a number\n"); // [3]
        if (isinf(z)) printf("z is infinite\n");
 
        long double r;  // [4]
 
        r = 7.0 - 3.0/(z - 2.0 - 1.0/(z - 7.0 + 10.0/(z - 2.0 - 2.0/(z - 3.0)))); // [5]
 
        feclearexcept(FE_DIVBYZERO); // [6]
 
        bool raised = fetestexcept(FE_OVERFLOW); // [7]
        if (raised) printf("Unanticipated overflow-- investigate this./n");
 
        return r;
}
 
void main()
{
       #pragma STDC FENV_ACCESS ON 
 
        #ifdef TEST_NUMERIC_STABILITY_UP
        fesetround(FE_UPWARD);                   // [8]
        #elif TEST_NUMERIC_STABILITY_DOWN
        fesetround(FE_DOWNWARD); 
        #endif
 
        printf("%.7g\n", compute_fn(3.0));
        printf("%.7g\n", compute_fn(NAN));
}

Footnotes:

[1] As the IEEE 754 status flags are manipulated in this function, this #pragma is needed to avoid the compiler incorrectly rearranging such tests when optimising.

[2] C99 defines a limited number of expression evaluation methods: the current compilation mode can be checked to ensure it meets the assumptions the code was written under (Note: gcc 4.4.5 currently uses a non-standard name __FLT_EVAL_METHOD__ for this).

[3] The special values such as NaN and positive or negative infinity can be tested and set.

[4] long double is defined as IEEE 754 double extended or quad precision if available. Using higher precision than required for intermediate computations can minimize round-off error . (the typedef double_t can be used for code that is portable under all FLT_EVAL_METHODs).

[5] The main function to be evaluated. Although it appears that some arguments to this continued fraction, e.g. 3.0, would lead to a divide-by-zero error, in fact the function is well-defined at 3.0 and division by 0 will simply return a +infinity that will then correctly lead to a finite result: IEEE 754 is defined not to trap on such exceptions by default and is designed so that they can very often be ignored, as in this case. (Note that if FLOAT_EVAL_METHOD is defined as 2 then all internal computations including constants will be performed in long double precision; if FLT_EVAL_METHOD is defined as 0 then additional care is need to ensure this, including possibly additional casts and explicit specification of constants as long double).

[6] As the raised divide-by-zero flag is not an error in this case, it can simply be dismissed to clear the flag for use by later code.

[7] In some cases other, exceptions may be an error, such as overflow (although it can in fact be shown that this cannot occur in this case).

[8] The default rounding mode is round to even for IEEE 754, but explicitly setting the rounding mode toward + and - infinity (by defining TEST_NUMERIC_STABILITY_UP etc in this example, when debugging) can be used to diagnose numerical instability . Note that this method can be used even if compute_fn() is part of a separately compiled binary library.

Version detection

A standard macro __STDC_VERSION__ is defined with value 199901L to indicate that C99 support is available. As with the __STDC__ macro for C90, __STDC_VERSION__ can be used to write code that will compile differently for C90 and C99 compilers, as in this example that ensures that inline is available in either case (by replacing it with static in C90 to avoid linker errors.)

#if __STDC_VERSION__ >= 199901L
  /* "inline" is a keyword */
#else
# define inline static
#endif

Implementations

Most C compilers now have support for at least some of the features new to C99. However, there has been less support from vendors such as Microsoft that have mainly focused on C++.

Implementation	Level of support	Details
AMD x86 Open64 Compiler Suite	Mostly	Has C99 support equal to that of GCC.
cc65	Partial	Full C89 and C99 support is not implemented, partly due to platform limitations (MOS Technology 6502). There is no support planned for some C99 types like _Complex and 64-bit integers (long long).
Ch	Partial	Supports major C99 features.
Clang	Mostly	C99 floating-point pragmas are the only unsupported feature.
C++ Builder	Mostly [citation needed]
Digital Mars C/C++ Compiler	Partial	Lacks support for some features, such as tgmath.h and _Pragma.
GCC	Mostly	As of July 2011 in mainline GCC, 43 features have been completely implemented (12 suffer library issues), 1 feature is broken and 6 are missing. The latest stable release, GCC 4.6, also provides the same level of compliance.
IBM C for AIX, V6 and XL C/C++ V11.1 for AIX	Full
IBM Rational logiscope	Full	Until Logiscope 6.3, only basic constructs of C99 were supported. C99 is officially supported in Logiscope 6.4 and later versions.
The Portland Group PGI C/C++	Full
Intel C++ compiler	Mostly
Microsoft Visual C++	No	As of Visual C++ 2010, there are no plans to support C99.
Open Watcom	Partial	Implements the most-used parts of the standard. However, they are enabled only through an undocumented command-line switch.
Pelles C	Mostly	Supports most C99 features.
Portable C compiler	Partial	Working towards becoming C99-compliant.
Sun Studio	Full
Tiny C Compiler	Mostly	Does not support complex numbers or variable length arrays. The developers state that "TCC is heading toward full ISOC99 compliance".

Future work

Since ratification of the 1999 C standard, the standards working group prepared technical reports specifying improved support for embedded processing, additional character data types (Unicode support), and library functions with improved bounds checking. Work continues on technical reports addressing decimal floating point, additional mathematical special functions, and additional dynamic memory allocation functions. The C and C++ standards committees have been collaborating on specifications for threaded programming.

The next revision of the C standard, C11, was ratified in 2011. The C standards committee adopted guidelines that limited the adoption of new features that have not been tested by existing implementations. Much effort went into developing a memory model, in order to clarify sequence points and to support threaded programming.

See also

• C11
• C++11
• C++ Technical Report 1
• floating point for further discussion of usage of IEEE 754 hardware

Further reading

• Cheng, Harry (1 March 2002). "C99 & Numeric computing". Dr. Dobb's Journal. http://drdobbs.com/cpp/184404993. 
• Seebach, Peter (24 March 2004). "Open source development using C99". developerWorks. IBM. http://www.ibm.com/developerworks/library/l-c99.html. 

External links

• Final version of the C99 standard with corrigenda TC1, TC2, and TC3 included, formatted as a draftPDF (3.61 MB)
• New in C9X
• Kuro5hin: Are you Ready For C99?

Preceded by C89 / C90 / "ANSI C"

C language standards

Succeeded by C11