C Language Support#

This page describes the C language EmbCC accepts: the --std= values and what they change, the predefined macros that describe the language, and each feature of C89, C99, C11, C17 and C23 with its status. For every feature that is partial or refused it quotes the diagnostic EmbCC prints, so that the message can be searched for. It is for people porting C code to EmbCC and for people deciding which constructs a portable program can use. GNU and Clang extensions (statement expressions, __attribute__, builtins, pragmas) are in Extensions. Choices the standard leaves to the implementation, such as the signedness of char, are in Implementation-defined behavior. C++ is in C++ support.

Summary#

EmbCC compiles one C dialect:

• the C17 language, which is C11 with the corrections of ISO/IEC 9899:2018;
• the subset of C23 listed under C23;
• the GNU extensions described in Extensions.

--std= does not select a different dialect, and __STDC_VERSION__ is 201710L whatever it names.

As a rule, a construct EmbCC does not implement is refused with an error that names it. The exceptions are the places where EmbCC accepts a program the standard requires it to diagnose, or gives a program a meaning other than the standard's. Check these first when porting code:

• Struct, union and enum tags, typedef names and enumeration constants declared in a block remain visible to the end of the translation unit. See Scope of tags, typedefs and enumeration constants.

EmbCC is also stricter than the standard in one place that commonly affects existing code: an empty parameter list () always means "no parameters" (details). A non-void function that can reach its closing brace gets a warning that is on by default (details).

Features whose availability depends on the target (variable length arrays on AVR, long double, __int128, atomic sizes, thread-local storage) are in Target-dependent features.

The tables below use three statuses:

Diagnostics are quoted without their embcc: FILE:LINE:COL: error: prefix. The format is described in Diagnostics.

Selecting a standard#

--std=STANDARD#

GCC: -std=STANDARD.

Name a C standard. Each is compiled as it is: its keywords, its __STDC_VERSION__, C89's implicit int and C99's // comments, the unprototyped int f() before C23, and trigraphs under a strict standard before C23. The full rules are under --std=.

The default is gnu17. A cNN value defines __STRICT_ANSI__. -ansi is --std=c89. Any other value is an error:

embcc: error: unknown standard '-std=c3x'

--pedantic and --pedantic-errors report, as a warning or an error, what the standard does not have: a later standard's feature, or a GNU extension.

See Diagnostics.

The C++ values (c++20, gnu++17, ...) are described in Invoking EmbCC and C++ support.

Keywords#

Because there is one dialect, the C23 keywords are recognized in every compilation. alignas, alignof, nullptr, static_assert, thread_local, typeof and typeof_unqual are reserved and cannot be used as identifiers. auto, bool, constexpr, false and true are recognized from context, so code that declares its own entity of one of those names keeps its meaning:

typedef int bool;        /* accepted: bool is this typedef     */
enum { false, true };    /* accepted: true is this enumerator  */
int constexpr = 1;       /* accepted: constexpr is a variable  */

The GNU keywords (asm, __typeof__, __attribute__, ...) are in Extensions.

Testing for features in source code#

• #if __STDC_VERSION__ >= 202311L is false by default, although many C23 features are available; it is true under --std=c23. Test for the feature, or for __EMBCC__.
• __has_c_attribute(NAME) is defined, but evaluates to 0 for every name, including the standard attributes EmbCC accepts.
• __has_include works as specified.
• None of the __STDC_NO_ATOMICS__, __STDC_NO_COMPLEX__, __STDC_NO_THREADS__ or __STDC_NO_VLA__ macros is defined. Where a target cannot compile one of these features, the compilation fails with the error given under Target-dependent features.

Predefined macros#

The macros the C standard defines. The target's macros (__x86_64__, __SIZEOF_INT128__, ...) are listed by --dump-predef and described in Targets. EmbCC also defines __EMBCC__ as 1; it does not define __GNUC__ when compiling C.

C89 and C90#

C95 (Amendment 1)#

C99#

C11#

C17#

C17 adds no language features; it corrects C11. __STDC_VERSION__ has C17's value, 201710L.

C23#

Later drafts#

The following features of the C2y working draft are not supported:

Case ranges, case 1 ... 3:, are accepted as a GNU extension; see Extensions.

Target-dependent features#

The language features whose availability depends on the target. The targets are described in Targets: "x86-64" covers the ELF, EmbLinkOS and Linux triples, "AArch64" covers the ELF, EmbLinkOS and Linux triples, and "Cortex-M" covers every thumb* triple. Every compile for the Windows target also prints the --warn=windows-abi warning described there.

"One shared instance" means the object is placed in .tbss but addressed as an ordinary static object; see Targets.

The errors for the "No" entries:

The text in square brackets names the internal operation that could not be lowered.

Feature notes#

Functions that can reach their closing brace#

A function with a non-void return type should end every path with a return statement. The standard allows control to reach the closing brace as long as the caller does not use the value, so EmbCC accepts it, with a warning that is on by default (--error=return-type makes it an error):

warning: control may reach the end of 'f', which returns int [--warn=return-type] [E0008]

The function returns 0 when control reaches the brace, if its result is an integer or a pointer, rather than whatever its return register held. A caller that uses the value then reads the same thing every time. A floating or aggregate result is undefined there.

main is the exception the standard makes: reaching its closing brace returns 0, without a warning.

A path also ends at an infinite loop, at a call to a function declared _Noreturn, [[noreturn]] or __attribute__((noreturn)), and at a call to exit, _Exit, abort, __builtin_unreachable or __builtin_trap. embcc --explain E0008 describes the rule; see Diagnostics.

Case labels in nested statements#

A case or default label can be anywhere in its switch statement's body: in a nested block, in an if, or inside a loop, which the switch then enters in the middle (Duff's device). This follows C11 6.8.4.2. A nested switch has its own labels. Duplicate values and a second default are errors at any nesting depth, and a label with no switch around it is an error ('case' outside of a switch).

Empty parameter lists#

A function declarator with an empty parameter list, int f();, declares a function with no parameters, as in C23, whatever --std= says. Code that relies on the older meaning, "parameters not specified", is refused:

Scope of tags, typedefs and enumeration constants#

Objects, functions and labels have the scopes the standard gives them. A struct, union or enum tag, a typedef name and an enumeration constant are different: there is one namespace for each kind per translation unit, and a declaration in a block stays visible after the block ends. This has three consequences.

A name declared in a block can be used outside it, which the standard does not allow:

int f(void) { typedef int T; struct S { int a; } s = { 1 }; return s.a; }
int g(void) { T y = 2; struct S z = { y }; return z.a; }   /* accepted */

The same name declared with a different meaning in two blocks, or in a block and at file scope, is refused although the standard allows it:

The last two would otherwise give the name two meanings in one program -- the constant in one place, the variable in another -- so they are refused rather than resolved either way. At file scope, an enumeration constant and a variable or function of the same name are the standard's redeclaration error:

error: 'g' redeclared as a different kind of symbol: it is also the function on line 2

A tagged structure or union, or any enumeration, cannot be defined inside a type name in an expression (a cast, sizeof, a compound literal):

error: define structs/unions at file scope (block-scope type definitions are not supported)
error: define enums at file scope (block-scope type definitions are not supported)

An untagged structure in a cast, (struct { int a; } *)p, is accepted.

A structure, union or enumeration tag declared in a block belongs to that block, as the standard specifies: two functions may each define union u, and an inner block's struct s { ... } declares a new type that hides an outer struct s until the block ends (CMSIS's cmsis_gcc.h defines union llreg_u inside each of its 64-bit DSP intrinsics). A local variable or a parameter may share its name with a typedef name or with an enumeration constant declared before it, and hides it, as the standard specifies. That includes an array bound:

enum { N = 3 };
int f(void) { int N = 5; int a[N]; return sizeof a; }   /* 20, a VLA of five */

Const qualification#

const is part of a type, at every level: const char * and char *const are different types from char * and from each other. An lvalue whose type is const-qualified, or a structure or union with a const member at any depth, cannot be modified. Each of these is an error, as the standard requires:

const int limit = 10;
void f(void) { limit = 11; }        /* assignment of read-only 'limit' */
void g(const int *p) { *p = 3; }    /* assignment of a read-only location */
void h(void) { limit++; }           /* increment of read-only 'limit' */

error: assignment of read-only 'limit' (its type is const int)
error: assignment of a read-only location (its type is const int)
error: assignment of struct S, which has a const member

A member of a const structure is const, and so is an element of a const array. Initialization is not assignment: a const object takes its value from its initializer.

Converting a pointer to a const-qualified type into a pointer whose pointed-to type is not const, without a cast, is diagnosed with the warning -Wdiscarded-qualifiers, which is on by default as in GCC:

warning: initialization discards the 'const' qualifier of const char * [--warn=discarded-qualifiers]

A cast removes const without a diagnostic. A const object with static storage duration is placed in a read-only section (.rodata). __auto_type and the value of an expression drop the qualifiers; typeof keeps them, and typeof_unqual drops them.

Enumeration constants#

An enumeration with a fixed underlying type, enum E : unsigned char, has that type, and so do its constants. A value that the underlying type cannot represent is refused:

error: enumerator 'B' is 256, which the underlying type unsigned char cannot represent

An enumeration without a fixed underlying type is int (two bytes on AVR) while every value fits int, and its constants then have type int. A constant outside the range of int, which C17 does not allow and C23 does, is accepted without a diagnostic. The enumeration then takes the first of these types that can represent every value, and, as C23 specifies, its constants take that type too:

1. unsigned int, unsigned long, then unsigned long long, if no value is negative;
2. long, then long long, otherwise.

enum big { HUGE = 0x100000005 };      /* unsigned long on x86-64: sizeof(enum big) is 8 */
long long f(void) { return HUGE; }    /* returns 0x100000005 */

Where this choice differs from GCC's and Clang's is described in Implementation-defined behavior. --enums=short is refused (see Targets).

A value of 2^63 or more, from an unsigned long long initializer, is that value: enum { X = 0xffffffffffffffff } is an unsigned long enumeration on the 64-bit targets, and X > 0. Two enumerations have no type that can represent every value, and are refused:

error: the enumeration's values run from -1 to 9223372036854775808, which no integer type holds
error: enumerator 'B' would be one past LLONG_MAX, which no integer type the enum can have holds

The first is a negative value together with one of 2^63 or more. The second is a constant without an initializer that follows LLONG_MAX (or, with ULLONG_MAX in the message, follows ULLONG_MAX).

Inline functions#

EmbCC follows C11 6.7.4p7. When every file-scope declaration of a function with external linkage in a translation unit says inline and none says extern, its definition there is an inline definition:

• It provides no external definition. No symbol is defined for it in the object.
• The optimizer may inline its calls. A call that is not inlined, every call at --opt=none, and any use of its address refer to the external definition, which is an undefined symbol in this object.
• Exactly one translation unit of the program must provide the external definition. The usual way is a declaration with extern, or without inline, in one .c file that includes the header:

/* twice.h */
inline int twice(int x) { return 2 * x; }

/* twice.c -- the one external definition */
#include "twice.h"
extern inline int twice(int);

A static inline function is unaffected: it has internal linkage, and each unit that uses it has its own copy. A function that is main, a constructor or destructor, __attribute__((used)), or the target of an alias is always emitted.

GNU89 semantics apply instead with -fgnu89-inline, with --std=c89, --std=c90, --std=iso9899:1990, --std=gnu89 or --std=gnu90, and for a function with __attribute__((gnu_inline)). Under them a definition that says inline alone is an external definition, and one that says extern inline is used only for inlining and never emitted. See -fgnu89-inline.

Whether a call is inlined is decided by the optimizer; see Optimization.

Variable length arrays#

Supported: VLAs of any number of dimensions at block scope, VLA parameters, pointers to VLAs and [*] in prototypes. The size expression is evaluated once, where the declaration is reached; sizeof of a VLA is computed at run time; the storage is released when control leaves the block, including by break, continue and goto. This includes a typedef of a variably modified type, whose size is fixed where the typedef is declared: after int n = 3; typedef int row[n]; n = 10;, sizeof(row) is 12.

Refused:

A goto or switch that jumps into the scope of a VLA is not diagnosed, although the standard requires a diagnostic.

Complex types#

float _Complex, double _Complex and long double _Complex are supported, with all arithmetic operators. A bare _Complex is double _Complex. <complex.h> defines complex, I and _Complex_I and declares the library functions. long double _Complex depends on the target; see Target-dependent features.

GNU's integer complex types, _Complex int, short _Complex, unsigned long long _Complex and the rest, are supported too, and so is an integer imaginary constant, 2i, which is a _Complex int. * and / of two of them are computed in the integer type, as GCC computes them. A product is (ac - bd) + (ad + bc)i. A quotient uses GCC's scaled method, each division truncating: when |c| < |d|, with r = c / d, it is ((ar + b) + (br - a)i) / (cr + d); otherwise, with r = d / c, ((br + a) + (b - ar)i) / (dr + c). So (3+4i) / (1-2i) is -2+1i, as GCC has it; clang's formula gives -1+2i.

A complex object with static storage duration takes an initializer that EmbCC can fold. Otherwise:

error: a static complex initializer must be a constant that EmbCC folds: literals, casts, + and -, and scaling by a real

This rules out a product or quotient of two complex values, and CMPLX(1.0, 2.0), which <complex.h> defines as a call to a library function. At block scope both are accepted.

Half-precision floating point#

_Float16 (C23 Annex X) is IEEE 754 binary16 on every target: two bytes, aligned like a short, with an 11-bit significand. An operation on _Float16 operands has type _Float16, and each one is rounded to binary16. EmbCC computes it in float and rounds the result, which is exact, because a float's 24 bits are enough that rounding twice never differs from rounding once. So a program gets the answers of a machine with binary16 arithmetic, such as Arm's FEAT_FP16 or RISC-V's Zfh, on every target. FLT_EVAL_METHOD is 0.

GCC and clang on x86-64 evaluate instead in float, and round only at an assignment, a cast or a return. They may evaluate a constant in float too: 0.1f16 + 0.2f16 is 0x34cc with EmbCC and 0x34cd with GCC there. Where the two must agree, cast each intermediate result and constant to _Float16.

A constant takes the f16 or F16 suffix, and is rounded once from its digits. A conversion from double or long double is rounded once from that value, never through float.

__fp16 is Arm's storage format: the same binary16 bits, but a value read from one is a float, as a char read is an int. a + b of two __fp16 is a float, rounded once when it is stored, and through ... an __fp16 is a double. _Float16 and __fp16 are distinct types to _Generic.

__bf16 is bfloat16: the top half of a float, with its 8-bit exponent and an 8-bit significand, in two bytes. It works as _Float16 does, on every target: an operation on two of them, or on one and an integer, is a __bf16, each rounded to bfloat16; with a float it is a float; and with a _Float16 it is a _Float16, as in GCC and clang. A constant takes GCC's bf16 or BF16 suffix. A conversion to __bf16 from double, long double or an integer is rounded once: through a float, 2^24 + 2^16 + 1 would land on a half-way point and round down. The conversions are inline integer arithmetic, so no runtime routine is called. The exception is a 64-bit integer on AVR and RX, whose double is four bytes; there, __embcc_ll2bf and __embcc_ull2bf in lib/rt/half.c do it. The __BFLT16_MANT_DIG__ family of predefined macros describes it. A __bf16 travels between functions as a _Float16 does.

The predefined __FLT16_MANT_DIG__, __FLT16_MAX__ and the rest of that family are always defined. <float.h> defines FLT16_MANT_DIG and the other FLT16_ names when __STDC_WANT_IEC_60559_TYPES_EXT__ is defined before it is included.

A _Float16 argument or result travels as the target's calling convention passes one, so a function compiled by EmbCC can call or be called by one compiled by GCC or clang:

A struct holding a _Float16 is passed like any other struct. On AArch64 a struct of two to four of them is a homogeneous aggregate, in h0 to h3. With the ARM hard-float convention, which also gives each member a floating-point register of its own, it is refused:

error: 'f': a struct holding a _Float16, passed or returned by value, is not supported yet with the hard-float calling convention, which puts each binary16 member in a floating-point register of its own; pass a pointer to it

The same refusal applies to RISC-V's hard-float conventions. A _Float16 passed through ... is refused on every target, because it is not promoted there:

error: 'printf': passing a _Float16 through '...' is not supported yet: it is not promoted there, and EmbCC does not yet place an unpromoted binary16 among the variable arguments; convert it to double, as va_arg will read it

The conversions between binary16 and the wider formats are calls to EmbCC's runtime, lib/rt/half.c. They use integer arithmetic only, so a target without a floating-point unit pays for no soft-float call there. On AArch64 each conversion is one fcvt instruction instead. The routines are named as libgcc names them where libgcc has them: __extendhfsf2, __truncsfhf2 and __truncdfhf2 on x86-64, and __gnu_h2f_ieee, __gnu_f2h_ieee and __gnu_d2h_ieee on ARM. On the other targets the names are EmbCC's own, __embcc_h2f and the rest, so a program linked against another runtime gets a link error naming the routine. On macOS the system's compiler-rt provides them.

Generic selection#

_Generic selects the association whose type is the type of the controlling expression after lvalue conversion, which removes the expression's own qualifiers and _Atomic. Types are compared exactly: long and long long are different types even on targets where they have the same size, plain char is neither signed char nor unsigned char, and const, volatile and _Atomic in a pointed-to type count:

_Generic((const char *)0, char *: 1, default: 2)   /* 2 */
_Generic(1, const int: 1, default: 2)              /* 2: the operand is an int */
_Generic(1L, long long: 1, long: 2)                /* 2 */

A selection in which two associations have the same type is refused, as the standard requires:

error: more than one _Generic association matches type int: two associations name the same type

Atomic types#

The operators on an _Atomic object (load, store, ++, -- and the compound assignments) are atomic for integer and pointer types. Other types are refused, with one of:

error: reading an _Atomic double is not supported: EmbCC makes the operators atomic for integers and pointers only
error: assigning to an _Atomic struct s is not supported: EmbCC makes the operators atomic for integers and pointers only
error: a compound assignment to an _Atomic double is not supported: EmbCC makes the operators atomic for integers and pointers only

The sizes each target supports are in Target-dependent features. On x86-64 and AArch64 the operators handle up to 8 bytes; a 16-byte _Atomic __int128 is refused with an atomic access of 16 bytes is not one access on this target (it moves 8 at once): ..., while the <stdatomic.h> functions and the __atomic_* builtins handle 16 bytes on those targets.

<stdatomic.h> is the C library's interface over the compiler's atomic builtins; see Libraries and Extensions.

Alignment specifiers#

_Alignas(N), _Alignas(type) and _Alignof(type) are supported on objects and structure members, in any order among the declaration specifiers. An automatic array, structure or union may have an alignment larger than the stack's own (16 bytes; 8 on Cortex-M), and gets it. The alignas and alignof spellings are keywords (see Keywords). The cases the standard constrains, and the ones EmbCC limits, are handled as follows:

_Alignof applied to an expression is a GNU extension; see Extensions.

Initializers#

• Empty initializer. = {} zero-initializes the whole object: a scalar, an array, a structure or a union of any storage duration, a nested aggregate ({ {}, 1 }) and a compound literal ((struct p){}). A VLA cannot be initialized; see Variable length arrays.

• Flexible array members. See the C99 table.

• File-scope compound literals. See the C99 table.

• Brace elision in an array of unknown size. When an initializer that omits inner braces could give the array a different number of elements depending on the types of its expressions, the declaration is refused rather than sized one way:

  error: cannot size 'g' from its initializer: the braces it leaves out read as 2 elements without the types and 1 with them; brace each element
  

  This happens, for example, with struct pt { int x, y; }; static struct pt g[] = { 1 ? 2 : 3, 4 };. Bracing each element, { { 1 ? 2 : 3, 4 } }, is accepted.

• Braces around a scalar. One level is accepted, int q = { 4 };. More is refused: braces around a scalar initializer take one level.

Constexpr objects#

constexpr declares a named integer constant, at file scope or in a block, usable wherever an integer constant expression is:

constexpr int N = 4;
constexpr long long BIG = 5000000000;
int table[N];

A constexpr name has no storage, which is why its address cannot be taken. typeof and auto cannot see its type (see Type inference).

Type inference#

typeof(...) and typeof_unqual(...) accept a type name or an expression. auto (C23) and __auto_type (GNU) declare an object whose type is that of its initializer. All three determine an expression's type before the rest of the semantic analysis, and accept these expression forms: identifiers of objects (including parameters and function pointers), integer, floating, character and narrow string constants, nullptr, casts, calls, subscripts, *, & of an object, . and ->, unary -, ! and ~, the binary arithmetic, bitwise, shift, comparison and logical operators, pointer arithmetic and ?:. The type follows the usual conversions: typeof(c + c) with char c is int, and typeof(arr) keeps the array type.

Other forms are refused: compound literals, sizeof and _Alignof, ++ and --, assignments, the comma operator, a function name, wide string literals, __real__ and __imag__, _Generic, statement expressions, and enumeration and constexpr constants (including true and false). The diagnostic is

error: typeof of an unsupported expression

for typeof, and for auto and __auto_type

error: __auto_type cannot see the type of this initializer

An assignment or comma expression inside typeof is a syntax error, for example expected ')' after typeof before ','.

auto infers a type only at block scope, for one declarator, with an initializer and no other specifiers before it except static:

auto int x; is the C89 storage class and is accepted.

Attributes#

The [[...]] syntax shares its implementation with __attribute__((...)): [[gnu::NAME]] is the GNU attribute NAME, and the standard attributes map onto GNU ones (maybe_unused to unused, nodiscard to warn_unused_result, _Noreturn to noreturn). Any attribute namespace is dropped, so [[gnu::packed]] and [[packed]] are the same attribute. The GNU attributes and how each is handled are listed in Extensions.

[[...]] is accepted in these positions:

• at the start of a declaration, at file scope and in a block;
• after struct, union or enum: struct [[gnu::packed]] S { ... };;
• before a parameter declaration: int f([[maybe_unused]] int a);
• after a function declarator: void f(void) [[gnu::noinline]];;
• before a statement, including the empty attribute statement [[fallthrough]]; and an empty list [[]].

It is refused after the declarator of an object, and after an array declarator, with expected an expression, got '[', and on an enumerator with expected '}' before '['. An attribute at the start of a declaration that declares no object or function, [[gnu::packed]] struct S { ... };, applies to nothing and is ignored without a diagnostic; put a type attribute after the struct keyword.

An attribute EmbCC does not know is ignored with a --warn=attributes warning, as for the GNU syntax.

Embedding binary data#

#embed "file" and #embed <file> expand to the bytes of the file as a comma-separated list of integer constants, for use in an initializer:

static const unsigned char logo[] = {
#embed "logo.bin"
};

The file is searched for as #include searches for a header: a quoted name first in the directory of the file that contains the directive, then in the include directories; an angle-bracketed name in the include directories only. An empty file expands to nothing.

__has_embed is not supported.

Headers#

The headers EmbCC ships are described in Libraries. The language-related declarations they do not provide:

CMPLX, CMPLXF and CMPLXL are defined as function calls; see Complex types.

Preprocessor#

The preprocessor is integrated in embcc; -E writes its output. The command-line options that control it (-D, -U, -I, --system-include, the dependency options) are in Invoking EmbCC. The GNU directives and operators (#include_next, __has_include_next, __has_builtin, __has_attribute, #pragma pack, ...) are in Extensions.

Translation phases#

A backslash-newline inside a string literal or character constant gives:

error: unknown escape '\
' in a literal

Directives#

Conditional expressions#

#if and #elif support defined, the unary operators + - ~ !, the binary arithmetic, shift, relational, equality, bitwise and logical operators, and parentheses. Identifiers that are not macros evaluate to 0, except true, which evaluates to 1. Integer constants may be decimal, octal, hexadecimal or binary, with digit separators; character constants have the value they have in code. Differences from the standard:

Macro expansion#

Object-like and function-like macros, the # and ## operators, variadic macros with __VA_ARGS__, __VA_OPT__, empty arguments and rescanning are supported. Stringizing (#) differs from the standard in its handling of white space:

Runs of white space inside an argument, including a line break, are kept as written instead of becoming one space, and the space after each comma between variadic arguments is dropped.

Feature-test operators#