Editing C syntax (section)

==Miscellaneous==

===Reserved keywords===
The following words are [[reserved word|reserved]], and may not be used as identifiers:

{{col-begin}}
{{col-break|width=20%}}
:{{mono|_Alignas}}
:{{mono|_Alignof}}
:{{mono|_Atomic}}
:{{mono|auto}}
:{{mono|_Bool}}
:{{mono|break}}
:{{mono|case}}
:{{mono|char}}
:{{mono|_Complex}}
:{{mono|const}}
:{{mono|continue}}
:{{mono|default}}
:{{mono|do}}
{{col-break|width=20%}}
:{{mono|double}}
:{{mono|else}}
:{{mono|enum}}
:{{mono|extern}}
:{{mono|float}}
:{{mono|for}}
:{{mono|_Generic}}
:{{mono|goto}}
:{{mono|if}}
:{{mono|_Imaginary}}
:{{mono|inline}}
{{col-break|width=20%}}
:{{mono|int}}
:{{mono|long}}
:{{mono|_Noreturn}}
:{{mono|register}}
:{{mono|restrict}}
:{{mono|return}}
:{{mono|short}}
:{{mono|signed}}
:{{mono|sizeof}}
:{{mono|static}}
:{{mono|struct}}
{{col-break}}
:{{mono|switch}}
:{{mono|_Thread_local}}  <!-- new in C23 thread_local, seems its replacement -->
:{{mono|typedef}}
:{{mono|union}}
:{{mono|unsigned}}
:{{mono|void}}
:{{mono|volatile}}
:{{mono|while}}
{{col-end}}

Implementations may reserve other keywords, such as {{code|asm}}, although implementations typically provide non-standard keywords that begin with one or two underscores.

===Case sensitivity===
C identifiers are case sensitive (e.g., {{code|foo}}, {{code|FOO}}, and {{code|Foo}} are the names of different objects). Some linkers may map external identifiers to a single case, although this is uncommon in most modern linkers.

===Comments===
Text starting with the [[Lexical analysis#Token|token]] {{code|/*}} is treated as a [[comment (computer programming)|comment]] and ignored. The comment ends at the next {{code|*/}}; it can occur within expressions, and can span multiple lines. Accidental omission of the comment terminator is problematic in that the next comment's properly constructed comment terminator will be used to terminate the initial comment, and all code in between the comments will be considered as a comment. C-style comments do not nest; that is, accidentally placing a comment within a comment has unintended results:

<syntaxhighlight lang=C line="GESHI_FANCY_LINE_NUMBERS">
/*
This line will be ignored.
/*
A compiler warning may be produced here. These lines will also be ignored.
The comment opening token above did not start a new comment,
and the comment closing token below will close the comment begun on line 1.
*/
This line and the line below it will not be ignored. Both will likely produce compile errors.
*/
</syntaxhighlight>

[[C++]] style line comments start with {{code|//}} and extend to the end of the line. This style of comment originated in [[BCPL]] and became valid C syntax in [[C99]]; it is not available in the original K&R C nor in [[ANSI C]]:

<syntaxhighlight lang=C>
// this line will be ignored by the compiler

/* these lines
   will be ignored
   by the compiler */

x = *p/*q;  /* this comment starts after the 'p' */
</syntaxhighlight>

===Command-line arguments===
The [[parameter]]s given on a [[command line]] are passed to a C program with two predefined variables - the count of the command-line arguments in {{code|argc}} and the individual [[Parameter|arguments]] as [[character string]]s in the pointer array {{code|argv}}. So the command:

 myFilt p1 p2 p3

results in something like:
{|class="wikitable" style="font-family: monospace,monospace;"
|-
|m||y||F||i||l||t||style="background:#CCC;"|\0||p||1||style="background:#CCC;"|\0||p||2||style="background:#CCC;"|\0||p||3||style="background:#CCC;"|\0
|-
|colspan="7" align="center"|argv[0]||colspan="3" align="center"|argv[1]||colspan="3" align="center"|argv[2]||colspan="3" align="center"|argv[3]
|}

While individual strings are arrays of contiguous characters, there is no guarantee that the strings are stored as a contiguous group.

The name of the program, {{code|argv[0]}}, may be useful when printing diagnostic messages or for making one binary serve multiple purposes. The individual values of the parameters may be accessed with {{code|argv[1]}}, {{code|argv[2]}}, and {{code|argv[3]}}, as shown in the following program:

<syntaxhighlight lang=C>
#include <stdio.h>

int main(int argc, char *argv[])
{
    printf("argc\t= %d\n", argc);
    for (int i = 0; i < argc; i++)
        printf("argv[%i]\t= %s\n", i, argv[i]);
}
</syntaxhighlight>

===Evaluation order===
In any reasonably complex expression, there arises a choice as to the order in which to evaluate the parts of the expression: {{C-lang|(1+1)+(3+3)}} may be evaluated in the order {{C-lang|(1+1)+(3+3)}}, {{C-lang|(2)+(3+3)}}, {{C-lang|(2)+(6)}}, {{C-lang|(8)}}, or in the order {{C-lang|(1+1)+(3+3)}}, {{C-lang|(1+1)+(6)}}, {{C-lang|(2)+(6)}}, {{C-lang|(8)}}. Formally, a conforming C compiler may evaluate expressions in ''any'' order between ''[[sequence point]]s'' (this allows the compiler to do some optimization). Sequence points are defined by:
* ''Statement ends'' at semicolons.
* The ''sequencing operator'': a comma. However, commas that delimit function arguments are not sequence points.
* The ''short-circuit operators'': logical ''and'' ({{code|&&}}, which can be read ''and then'') and logical ''or'' (<code>||</code>, which can be read ''or else'').
* The ''[[?:|ternary operator]]'' ({{code|?:}}): This operator evaluates its first sub-expression first, and then its second or third (never both of them) based on the value of the first.
* Entry to and exit from a ''function call'' (but not between evaluations of the arguments).

Expressions before a sequence point are always evaluated before those after a sequence point. In the case of short-circuit evaluation, the second expression may not be evaluated depending on the result of the first expression. For example, in the expression {{C-lang|(a() {{!}}{{!}} b())}}, if the first argument evaluates to nonzero (true), the result of the entire expression cannot be anything else than true, so {{code|b()}} is not evaluated. Similarly, in the expression {{C-lang|(a() && b())}}, if the first argument evaluates to zero (false), the result of the entire expression cannot be anything else than false, so {{code|b()}} is not evaluated.

The arguments to a function call may be evaluated in any order, as long as they are all evaluated by the time the function is entered. The following expression, for example, has undefined behavior:
<syntaxhighlight lang=C>
 printf("%s %s\n", argv[i = 0], argv[++i]);
</syntaxhighlight>

===Undefined behavior===
{{main|Undefined behavior}}
{{unreferenced section|date=November 2011}}
An aspect of the C standard (not unique to C) is that the behavior of certain code is said to be "undefined". In practice, this means that the program produced from this code can do anything, from working as the programmer intended, to crashing every time it is run.

For example, the following code produces undefined behavior, because the variable ''b'' is modified more than once with no intervening sequence point:

<syntaxhighlight lang=C>
#include <stdio.h>

int main(void)
{
    int b = 1;
    int a = b++ + b++;
    printf("%d\n", a);
}
</syntaxhighlight>

Because there is no sequence point between the modifications of ''b'' in "''b''++ + ''b''++", it is possible to perform the evaluation steps in more than one order, resulting in an ambiguous statement. This can be fixed by rewriting the code to insert a sequence point in order to enforce an unambiguous behavior, for example:

<syntaxhighlight lang=C>
a = b++;
a += b++;
</syntaxhighlight>