ISO C: Difference between revisions

From dankwiki
m (Dank moved page ISO C99 to ISO C18: There have been at least three revisions since C99, heh)
(C11 atomics)
Line 22: Line 22:
* <tt>least{8,16,32,64}</tt>: Minimum native integer type having at least the specified width.
* <tt>least{8,16,32,64}</tt>: Minimum native integer type having at least the specified width.
* <tt>{8,16,32,64}</tt>: Integer type having precisely this width.
* <tt>{8,16,32,64}</tt>: Integer type having precisely this width.
==Atomics==
Introduced in C11, and exposed by <tt>stdatomic.h</tt>. Use <tt>_Atomic</tt> as a type specifier (ala <tt>volatile</tt> or <tt>const</tt>).
* Unlike other type specifiers, an atomic form of a base type might have different size/alignment than the base type.
* <tt>struct</tt>s and <tt>union</tt>s may be declared atomic, but it is then undefined behavior to access any of their members.
* Implementations are "encouraged to ensure that representation of C and C++ atomic types is the same."

Revision as of 10:34, 17 January 2021

Compilers

gcc

Threads

Aliasing

stdint.h

An excellent addition in C99. Type constructions of the form u?int{variety}_t (u prefix denotes unsigned). Varieties include:

  • ptr: Size sufficient to hold a pointer. This is useful for function type definitions, when it's unsure whether a pointer or integer type would be most appropriate for various instances (a void *'s size is not directly related to an int's size by the ANSI C standard).
  • max: Size sufficient to hold any other integer type.
  • fast{8,16,32,64}: Fastest integer type having at least the specified width.
  • least{8,16,32,64}: Minimum native integer type having at least the specified width.
  • {8,16,32,64}: Integer type having precisely this width.

Atomics

Introduced in C11, and exposed by stdatomic.h. Use _Atomic as a type specifier (ala volatile or const).

  • Unlike other type specifiers, an atomic form of a base type might have different size/alignment than the base type.
  • structs and unions may be declared atomic, but it is then undefined behavior to access any of their members.
  • Implementations are "encouraged to ensure that representation of C and C++ atomic types is the same."