C Programming Language Quiz

This quiz is about quirks of the programming language C and intended for fun and educational purpose. The one or the other question is more academic, i.e., it should make you think ;-)

Unless otherwise stated, the questions and corresponding answers are independent of a specific version of the C standard. Thus the answers are the same considering C89 up to and including C17 and probably future releases.

If two pointers p and q of the same type point to the same address, then p == q must evaluate to true.

Yes

No

Short answer: Comparing two pointers which are derived from two different objects which are not part of the same aggregate or union object invokes undefined behavior.

Have a look at this post for a detailed discussion.
Consider the following code snippet where an object of type int is accessed through lvalues of type short and unsigned char:
```
int i = 42;

short *s = (short *) &i;
unsigned char *c = (unsigned char *) &i;

*s;  // (A)
*c;  // (B)
```
(A) and (B) invoke undefined behavior

(A) invokes undefined behavior but (B) is legal

(B) invokes undefined behavior but (A) is legal

(A) and (B) are legal

The rule of thumb is: accessing an object of type T through an lvalue of type U where T and U are not compatible (modulo few exceptions) invokes undefined behavior—according to the strict aliasing rules. That means, in the example we accessed an object of type int through an lvalue of type short which leads to undefined behavior. One exception to the rule is that a character pointer may alias any other pointer, i.e., any object may be accessed through a character pointer.

Note, only type unsigned char is guaranteed to have no padding bits and therefore has no trap representation which could invoke undefined behavior (since C11 also signed char is guaranteed to have no padding bits).

Thus (A) invokes undefined behavior whereas (B) is legal.

Have a look at this post for a detailed discussion.

It may make a difference whether an integer constant is given in decimal or hexadecimal format. In other words the meaning may be different.

Yes

In a nutshell the type of an unsuffixed decimal constant is always signed whereas of a hexadecimal constant the type may be signed or unsigned.

C17 § 6.4.4.1 Integer constants ¶ 5

The type of an integer constant is the first of the corresponding list in which its value can be represented.

Suffix	Decimal Constant	Octal or Hexadecimal Constant
none	`int` `long int` `long long int`	`int` `unsigned int` `long int` `unsigned long int` `long long int` `unsigned long long int`

Thus for constants between INT_MAX+1 and UINT_MAX the type differs depending on whether the constant is given in decimal or hexadecimal format. In certain cases this might lead to unexpected effects. One example are functions with a variable number of arguments.

void foo(int n, ...);

void bar(void) {
  foo(42, 0x80000000);
  foo(42, 2147483648);
}

Depending on the ABI and width of integer types of a platform, the function calls may differ. For example, according to the ABI for the Arm 32-bit architecture an int and long are 32-bit wide and passed in one register whereas a long long is 64-bit wide and passed in two registers. Thus the call sides differ.

bar:
  push {r3, lr}

  // first call side
  // second argument is in r1 only
  mov r1, #-2147483648
  movs r0, #42
  bl foo

  // second call side
  // second argument is in r2 and r3
  mov r2, #-2147483648
  movs r3, #0
  movs r0, #42
  bl foo

  pop {r3, pc}

Of course, there are plenty examples about arithmetic expressions which suffer from this nuance as e.g.

uint64_t x = 0x80000000 << 1;
uint64_t y = 2147483648 << 1;

where x equals zero and y equals 2³² assuming that int is 32-bit wide.

We may not only run into different behavior on the same platform but also across which results in portability problems. Arithmetic expressions may lead to different results on different platforms. For example, expression -1 < 0x8000 evaluates to true on a platform where int is 32-bit wide and to false where int is 16-bit wide.

A further example where the type of a constant makes a difference are generic selections:

#define print_type_of(x) _Generic((x),  \
    unsigned int: puts("unsigned int"), \
    long: puts("long"))

print_type_of(0x80000000);
print_type_of(2147483648);

While speaking of generic selections the whole story may also lead to subtle situations in C++ where we have overloaded functions:

void foo(unsigned int x);
void foo(long x);

void bar() {
  foo(0x80000000);
  foo(2147483648);
}

Another, probably more contrived example, is sizeof(0x80000000) == sizeof(2147483648) which evaluates to false on a platform where int is 32-bit wide.

The following two function declarations can be used interchangeably, i.e., they mean exactly the same:
```
int foo();
int foo(void);
```
Yes

No

The short answer is that the former declares a function with an unknown number and types of arguments while the latter declares a function without any argument, i.e., it is a nullary function.

Have a look at this post for a detailed discussion.
The following function declaration in conjunction with the function definition is legal.
```
void foo();
void foo(int a) { }
```
Yes

No

That is a valid function declaration and definition. The declaration only introduces the function name foo without defining the number and types of arguments.

Have a look at this post for a detailed discussion.
The following function declaration in conjunction with the function definition is legal.
```
void foo();
void foo(float a) { }
```
Yes

No

This is not a valid function declaration in conjunction with the definition. The short answer is that whenever a function is called where no prototype is available, then the default argument promotions are applied. For example, a float is promoted to a double. In this case, the function type is not compatible with the function type after the default argument promotions.

Have a look at this post for a detailed discussion.
Consider function foo which does not return a value although the return type is int.
```
int foo() { }
```
Now consider two statements (A) and (B) which call function foo, respectively.
```
foo();        // (A)
foo() + 42;   // (B)
```
(A) and (B) invoke undefined behavior

(A) invokes undefined behavior but (B) is legal

(B) invokes undefined behavior but (A) is legal

(A) and (B) are legal
This is an artifact from the old days. In K&R C there exists no type void. Furthermore, in case no type was given, default type int was assumed. Thus, the following functions are equivalent in K&R C and both do not return a value:
```
f() { }

int g() { }
```
The implicit int rule was abandoned in C99 (see discussion N661 or C99 rationale). However, for the sake of downward compatibility, it is still legal to return no value. Though, using the value of the call invokes undefined behavior.

C17 § 6.9.1 Function definitions ¶ 12

If the } that terminates a function is reached, and the value of the function call is used by the caller, the behavior is undefined.

Fun fact: C++ differs in the sense that value-returning functions must return a value—independent whether the value of a call is used or not.

C++98 § 6.6.3 The return statement ¶ 2

[…] Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function.

A return statement without an expression can be used only in functions that do not return a value, that is, a function with the return type void, a constructor (12.1), or a destructor (12.4). A return statement with an expression of non-void type can be used only in functions returning a value; the value of the expression is returned to the caller of the function. The expression is implicitly converted to the return type of the function in which it appears. A return statement can involve the construction and copy of a temporary object (12.2). Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function.

Note, what may seem counterintuitive at first glance is that a C++ compiler may in general only emit diagnostics in such cases and not treat them as errors. The following example illustrates why this is the case.
```
template<typename T>
T call_or_abort(std::function<T(void)> f) {
    if (f)
        return f();
    else
        abort_program();
}
```
First of all there is no way to express a value of type T which could be returned in case the else branch is taken. Furthermore, in general it is not possible to prove whether function call abort_program() terminates or not. Thus, throwing an error would reject possibly valid C++ programs which is the reason why only a diagnostics is emitted, if at all.
Consider the following two declarations of function foo.
```
static void foo(void);
extern void foo(void);
```
Which linkage does function foo finally have?

Internal linkage

External linkage

Code invokes undefined behavior
This is defined in the following paragraph:

C17 § 6.2.2 Linkages of identifiers ¶ 4

For an identifier declared with the storage-class specifier extern in a scope in which a prior declaration of that identifier is visible,³¹⁾ if the prior declaration specifies internal or external linkage, the linkage of the identifier at the later declaration is the same as the linkage specified at the prior declaration. If no prior declaration is visible, or if the prior declaration specifies no linkage, then the identifier has external linkage.

31) As specified in 6.2.1, the later declaration might hide the prior declaration.

Fun fact: the other way around
```
extern void foo(void);
static void foo(void);
```
invokes undefined behavior which is caught by GCC as well as Clang:
```
test.c:2:13: error: static declaration of ‘foo’ follows non-static declaration
    2 | static void foo(void);
      |             ^~~
test.c:1:13: note: previous declaration of ‘foo’ was here
    1 | extern void foo(void);
      |             ^~~
```
Function parameter x is const-qualified in the function declaration but not in the function definition. Furthermore, parameter x is even written to in the function body. Is this legal?
```
void foo(int const x);
void foo(int x) {
    x = 42;
}
```
Yes

No

Type qualifiers are not considered while determining if two function parameters are compatible.

C11 § 6.7.6.3 Function declarators (including prototypes) ¶ 15

[…] In the determination of type compatibility and of a composite type, […] each parameter declared with qualified type is taken as having the unqualified version of its declared type. […]

For two function types to be compatible, both shall specify compatible return types.¹⁴⁶⁾ Moreover, the parameter type lists, if both are present, shall agree in the number of parameters and in use of the ellipsis terminator; corresponding parameters shall have compatible types. If one type has a parameter type list and the other type is specified by a function declarator that is not part of a function definition and that contains an empty identifier list, the parameter list shall not have an ellipsis terminator and the type of each parameter shall be compatible with the type that results from the application of the default argument promotions. If one type has a parameter type list and the other type is specified by a function definition that contains a (possibly empty) identifier list, both shall agree in the number of parameters, and the type of each prototype parameter shall be compatible with the type that results from the application of the default argument promotions to the type of the corresponding identifier. (In the determination of type compatibility and of a composite type, each parameter declared with function or array type is taken as having the adjusted type and each parameter declared with qualified type is taken as having the unqualified version of its declared type.)

146) If both function types are “old style”, parameter types are not compared.

This was also asked in DR040.
The return type for function foo is const-qualified in the function definition but not in the function declaration. Is this legal?
```
int foo(void);
int const foo(void) {
    return 42;
}
```
Yes

No
The answer to this question is neither right nor wrong. The overall consensus is that qualifiers for rvalues should be ignored. Though, strictly speaking the wording of the C standard up to and including C11 do not address this.

In C17 it was made explicit that type qualifiers should be ignored for rvalues, i.e., in particular for casts (C17 § 6.5.4 ¶ 5), lvalue conversion (C17 § 6.5.1.1 ¶ 2), and for function declarators:
C17 § 6.7.6.3 Function declarators (including prototypes) ¶ 5

If, in the declaration “T D1”, D1 has the form
```
D ( parameter-type-list )
```
or
```
D ( identifier-listopt )
```
and the type specified for ident in the declaration “T D” is “derived-declarator-type-list T”, then the type specified for ident is “derived-declarator-type-list function returning the unqualified version of T”.
The words “the unqualified version of” were added in C17 which have a greater impact than one might first suspect. Consider the following code:
```
int const foo(void) { return 42; }

void bar(void) {
    int       (*f)(void) = foo;
    int const (*g)(void) = f;
}
```
Both assignments are legal, although the return types of the function types are differently const-qualified.

Have a look at DR423 and DR481 for further discussions.
Consider the following translation unit consisting of a global variable declaration:
```
struct foo x;
struct foo { int i; }
```
At the point of the declaration of variable x the structure type foo is incomplete. Thus the size is unknown. Only later on in the translation unit the type is completed. Is this translation unit legal?

Yes

No
This is allowed in certain circumstances as e.g. for global variables. A similar argument holds for arrays with an incomplete type.
```
int array[];
int array[42];
```
This is also mentioned in DR016.
Declaring a variable of type void with internal linkage is not legal.
```
static void foo;
```
Is it legal to declare a variable of type void with external linkage?
```
extern void foo;
```
Yes

No

According to the grammar this is legal. Furthermore, it is nowhere explicitly stated in the C11 standard that it is not allowed. However, I cannot think of any real use case and therefore assume that this is only allowed by accident. Note, type void is incomplete and cannot be completed.

C11 § 6.2.5 Types ¶ 19

The void type comprises an empty set of values; it is an incomplete object type that cannot be completed.

Thus the only operation which comes to my mind is to take the address of variable foo. However, it turns out that expression foo is not a valid lvalue:

C11 § 6.3.2.1 Lvalues, arrays, and function designators ¶ 1

An lvalue is an expression (with an object type other than void) that potentially designates an object […]

An lvalue is an expression (with an object type other than void) that potentially designates an object;⁶⁴⁾ if an lvalue does not designate an object when it is evaluated, the behavior is undefined. When an object is said to have a particular type, the type is specified by the lvalue used to designate the object. A modifiable lvalue is an lvalue that does not have array type, does not have an incomplete type, does not have a const-qualified type, and if it is a structure or union, does not have any member (including, recursively, any member or element of all contained aggregates or unions) with a const-qualified type.

64) The name “lvalue” comes originally from the assignment expression E1 = E2, in which the left operand E1 is required to be a (modifiable) lvalue. It is perhaps better considered as representing an object “locator value”. What is sometimes called “rvalue” is in this International Standard described as the “value of an expression”.

An obvious example of an lvalue is an identifier of an object. As a further example, if E is a unary expression that is a pointer to an object, *E is an lvalue that designates the object to which E points.

It is unclear to me whether taking the address of such objects was legal in the past or not, since the definition of lvalues changed between standard revisions. At least for C11 I cannot think of any meaningful and conforming operation on external objects of type void.

The whole story is also discussed in DR012. There it has been pointed out that it is legal to take the address of object foo if the type is changed from void to const void. Again this looks more like an oversight to me than something which was intended.
The bit representation of the null pointer must have all bits zero.

Yes

No

The null pointer constant is defined by the C standard. However, the representation of the null pointer at run-time is not. Actually, the representation of pointers in general is not defined by the C standard. For example, the Symbolics Lisp Machine 3600 does not make use of numerical pointers at all but of tuples of the form <array-object, index>. The representation of the null pointer is then <nil, 0>. Have a look at clc FAQ 5.17 for further examples.
Constant 0 evaluates to an integer or the null pointer—depending on the context.
```
int  i = 0;
int *p = 0;
```
Yes

No
The expression (void *)0 evaluates to the null pointer.

Yes

No
If the expression e evaluates to 0, then it is guaranteed that (void *)e evaluates to the null pointer.

Yes

No

Only the null pointer constant converted to pointer type is guaranteed to equal the null pointer.
If the expression e evaluates to the null pointer, then it is guaranteed that e+0 evaluates to the null pointer, too.

Yes

No

Null pointer arithmetic is undefined behavior in C.
Is it possible that function foo is called?
```
int x;
if (x != x) foo();
```
Yes

No

Short answer: Yes, it is possible because variable x is uninitialized when read.

Long answer: the wording of the C standard has changed over time w. r. t. uninitialized variables, indeterminate values, and so on. Therefore, let us consider C11 for the moment which received the following update:

C11 § 6.3.2.1 Lvalues, arrays, and function designators ¶ 2

[…] If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined. […]

Except when it is the operand of the sizeof operator, the unary & operator, the ++ operator, the -- operator, or the left operand of the . operator or an assignment operator, an lvalue that does not have array type is converted to the value stored in the designated object (and is no longer an lvalue); this is called lvalue conversion. If the lvalue has qualified type, the value has the unqualified version of the type of the lvalue; additionally, if the lvalue has atomic type, the value has the non-atomic version of the type of the lvalue; otherwise, the value has the type of the lvalue. If the lvalue has an incomplete type and does not have array type, the behavior is undefined. If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined.

Thus according to the paragraph the code snippet invokes undefined behavior and therefore anything may happen including a function call to foo.

Why the special treatment of objects which may have register storage class? This constraint can be traced back to the Intel Itanium architecture (see DR338) which has general integer registers with 64-bit plus one trap bit. The trap bit indicates whether the register is initialized or not and is referred to as NaT, “not-a-thing”. Reading a register where the NaT bit is set may raise an exception.
Now consider a slightly modified version of the previous question. Is it possible that function foo is called?
```
int x;
&x;
if (x != x) foo();
```
Yes

No
In the previous example it is possible that function foo is called because the code invokes undefined behavior according to C11 section 6.3.2.1 paragraph 2. This time the address of variable x is taken and therefore the paragraph does not apply anymore.

The value of variable x is indeterminate, i.e., it is either a trap representation or an unspecified value. In the former case, reading a trap representation invokes undefined behavior (C11 § 6.2.6.1 ¶ 5) and therefore anything may happen including a function call to foo. In the latter case, if the value of x is unspecified, the expression x != x evaluates to an unspecified value, too. Thus the expression may evaluate to true or false which means that function foo may be called.

Have a look at DR260 or DR451 for further discussions of indeterminate and unspecified values. The prevailing opinion is that the value of an expression is indeterminate (unspecified) if a subexpression evaluates to an indeterminate (unspecified) value. For example, if x of type int is unspecified, then x *= 0 is unspecified, too. In particular this means it is not guaranteed that x equals zero after the assignment. Furthermore, unspecified values may be “unstable” or sometimes also referred to as “wobbly”.
```
unsigned char x;
printf("%i\n", x);
printf("%i\n", x);
```
In the example it is not guaranteed that the same value is printed twice. Thus, the value of x may change between the function calls. For further discussions have a look at N1793, N1818, N2012, N2013, N2221.
Again, consider a slightly modified version of the previous question. Is it possible that function foo is called?
```
unsigned char x, y;
memcpy(&x, &y, 1);
if (x != x) foo();
```
Yes

No

The type unsigned char is guaranteed to have no trap representations (C11 § 6.2.6.1 ¶ 3). Thus the initial value of x is unspecified.

According to an answer from a C committee member on StackOverflow the value of x should be specified after the call to the standard library function memcpy. Thus the expression x != x should evaluate to false. I'm saying should because I cannot find any evidence for that in the C standard. Having a look at DR451 the committees response is library functions will exhibit undefined behavior when used on indeterminate values which contradicts with the answer on StackOverflow. Therefore, I leave this question open.

Have a look at Uninitialized Reads for further discussions.
Let T be a (derived) object type. The assignment of cp is legal. Is the assignment of cpp legal, too?
```
T  *p  = /* something */;
T **pp = /* something */;

T const  *cp  = p;
T const **cpp = pp;
```
Yes

No

For this question I do not have a short answer. Have a look at this post for a detailed discussion.
The expression sizeof(int) > -1 evaluates to

true

false

The short answer is that operator sizeof returns an unsigned integer of type size_t. According to the usual arithmetic conversions (C11 § 6.3.1.8) the operand which is signed and has a lower rank than the unsigned operand, is converted to an unsigned integer type of the same rank as the unsigned operand. Any signed integer which is equivalent to -1 has all bits set. Such a sequence of bits interpreted as an unsigned integer equals the maximal unsigned integer of each corresponding integer rank. In other words (unsigned int)-1 equals UINT_MAX. The same holds true for all other integers short int, long int, and long long int. Thus, the left operand of the relational operator evaluates to the maximal unsigned integer representable by an unsigned integer whose rank is equivalent to the rank of size_t. Since there exists no unsigned integer with a same rank which is strictly greater, the expression always evaluates to false.
The following two statements are equivalent.
```
char x[] = "123";
char *x  = "123";
```
Yes

No

The first assignment initializes an array with automatic or static storage duration (depends on whether x is declared in file or function scope) which is modifiable. Whereas the second assignment initializes a pointer to an array with static storage duration which is not necessarily modifiable. Or in other words arrays are not pointers.

Have a look at this post for a detailed discussion.
Let int a[42]; be an array, then all three expressions a and &a and &a[0] evaluate to a pointer to the first element of the array, i.e., the following equalities hold:
```
(void *) a == (void *)&a
(void *) a == (void *)&a[0]
(void *)&a == (void *)&a[0]
```
Does this mean that all three expressions mean exactly the same and therefore can be used interchangeably?

Yes

No

All three expressions evaluate to a pointer to the first element of the array. However, each expression has a different type. Have a look at this post for a detailed discussion.
Assume that the variables a, b, and c are initialized before read.
```
uint8_t a, b, c;
/* ... */
uint8_t x = (a + b) / c;
uint8_t y = a + b;
uint8_t z = y / c;
```
The values for the variables x and z

may differ, i.e., x == z may evaluate to false.

are always the same, i.e., x == z always evaluates to true.

Short answer: The integer promotions require that the value of each variable is promoted to size int, then the addition and division is performed. The resulting value is truncated and stored in the corresponding variable of each assignment, respectively. Provided that the addition may overflow the values for x and z may not equal.

Long answer: The modulo operation is not distributive over division. Lets illustrate the problem by an example. Assume a=255;, b=1;, and c=2;, then for the first assignment we have that the value stored in x equals the expression ((255 + 1) / 2) % 256 which equals (256 / 2) % 256 which equals 128 % 256 which finally equals 128. For the second assignment we have that the value stored in y equals the expression (255 + 1) % 256 which equals 256 % 256 which finally equals 0. N.B. an overflow occurred which is defined behavior for unsigned integers. For the last assignment we then have that the value stored in z equals the expression (0 / 2) % 256 which equals 0 % 256 which finally equals 0. Therefore x == z is not always the case since 128 != 0.

Fun fact 1: The modulo operation is distributive over addition, i.e., (a + b) % x == [(a % x) + (b % x)] % x for all a,b,x. Thus, if we change the division by an addition, then the values for the variables x and z are always the same.

Fun fact 2: We could change the first assignment to uint8_t x = ((uint8_t)(a + b)) / c;. Then the values for the variables x and z are always the same, too.
Is the size of type char the same as the size of any character constant? That means, the expression sizeof(char) == sizeof('x') for any character constant 'x' evaluates to

true

false

Character constants have type int (C11 § 6.4.4.4 ¶ 10). Thus only sizeof(int) == sizeof('x') is guaranteed to evaluate to true.

N.B. in terms of the C11 standard a character constant is either an integer character constant or a wide character constant. The former is a sequence of one or more multibyte characters. Thus 'abc' is a valid integer character constant where the representation is implementation-defined. If an integer character constant contains a single character, then its value equals the integer representation of an object of type char which represents the very same single character.
Consider the following code snippet:
```
int x = 5, y = 7;
int z = x+++y;
```
The expression x+++y

leads to a compile error since operator +++ is not defined

invokes undefined behavior

is equivalent to (x++) + y

is equivalent to x + (++y)
In C you cannot define new operators like in C++. Thus such wired locking operators are a combination of existing operators. For example, --*-- is not a new operator but a valid combination of operators in the following code snippet:
```
int x[1] = { 0 };
int *p = &x[1];
--*--p;
```
Expression --*--p is equivalent to --(*(--p)) which evaluates to -1 and as a side-effect assigns -1 to x[0].
Consider the following code snippet:
```
int x;
int y = (x=1) + (x=2);
```
Code invokes undefined behavior.

Code is legal and the value of variable y equals

Operator precedence is well defined. However, the order of evaluation of arithmetic operands is undefined. Thus, the expression (x=1) + (x=2) invokes undefined behavior, i.e., it is undefined whether variable x should equal 1 or 2 after the assignments. This renders the whole code as undefined.

Fun fact: GCC 8.2.1 evaluates the expression to 4 and Clang 7.0.0 to 3 while using options -std=c11 -O2.
Consider the following code snippet:
```
int x;
int y = (x=1) && (x=2);
```
The value of variable y equals

anything because the code invokes undefined behavior

true

false

Operator precedence is well defined and for the logical operators && and || the order of evaluation of operands is well defined, too. With the words of the C standard: between the evaluation of the first and second operand there exists a sequence point. Thus in the example we have that first x=1 is evaluated which equals true and then x=2 is evaluated which also equals true which renders the whole expression true.
Which of the following two compilation units compile?
```
// Compilation Unit A
const int n = 42;
int x[n];

// Compilation Unit B
const int m = 42;
void foo(void) {
    int y[m];
}
```
Both compilation units compile.

Compilation unit A compiles but not B.

Compilation unit B compiles but not A.

Both compilation units do not compile.

Short answer: compilation unit A does not compile because global array x is a variable length array which is not allowed at file scope. However, a variable length array is allowed at block scope and therefore compilation unit B compiles.

For the long answer we first look up the definition of an integer constant expression:

C11 § 6.6 Constant expressions ¶ 6

An integer constant expression¹¹⁷⁾ shall have integer type and shall only have operands that are integer constants, enumeration constants, character constants, sizeof expressions whose results are integer constants, _Alignof expressions, and floating constants that are the immediate operands of casts. Cast operators in an integer constant expression shall only convert arithmetic types to integer types, except as part of an operand to the sizeof or _Alignof operator.

117) An integer constant expression is required in a number of contexts such as the size of a bit-field member of a structure, the value of an enumeration constant, and the size of a non-variable length array. Further constraints that apply to the integer constant expressions used in conditional-inclusion preprocessing directives are discussed in 6.10.1.

Thus, the expressions n and m which are used while declaring arrays x and y, respectively, are not integer constant expressions—although n and m are both variables which are const-qualified. If the size expression of an array declaration is not an integer constant expression we have the following:

C11 § 6.7.6.2 Array declarators ¶ 4

[…] If the size is an integer constant expression and the element type has a known constant size, the array type is not a variable length array type; otherwise, the array type is a variable length array type. […]

If the size is not present, the array type is an incomplete type. If the size is * instead of being an expression, the array type is a variable length array type of unspecified size, which can only be used in declarations or type names with function prototype scope;¹⁴³⁾ such arrays are nonetheless complete types. If the size is an integer constant expression and the element type has a known constant size, the array type is not a variable length array type; otherwise, the array type is a variable length array type. (Variable length arrays are a conditional feature that implementations need not support; see 6.10.8.3.)

143) Thus, * can be used only in function declarations that are not definitions (see 6.7.6.3).

Thus both arrays x and y are of type variable length array for which we have:

C11 § 6.7.6.2 Array declarators ¶ 2

If an identifier is declared as having a variably modified type, it shall be an ordinary identifier (as defined in 6.2.3), have no linkage, and have either block scope or function prototype scope. If an identifier is declared to be an object with static or thread storage duration, it shall not have a variable length array type.

Strictly speaking variable length arrays are a feature that implementations need not support and therefore there might exist a compiler which does not compile unit B, too. However, the takeaway message is that you cannot make use of variables in constant expressions although they are const-qualified. You might want to replace a variable with a preprocessor macro, but then you lose all type information, which has some drawbacks, too.

Fun fact: In C++ both compilation units compile fine. Though, C++ does not have the concept of variable length arrays and therefore y is compiled into an ordinary array consisting of 42 elements.
Consider the following function which includes a switch statement:
```
void foo(int x) {
    int i = 0;

    switch (x) {
        printf("-1");
        case 0: printf("0");
        if (0) {
            case 1: printf("1");
        } else {
            for (i = -1; i < x; ++i) {
                case 2: printf("2");
            }
        }
        case 3: printf("3");
    }
}
```
Code does not compile

Code compiles but invokes undefined behavior

Code is legal and after three consecutive function calls foo(0); foo(1); foo(2); the console output equals

02313223
The body of a switch statement may be an arbitrary statement which renders the given code legal. Before we go on let us have a look at some oddities.

Although the controlling expression of the if statement always evaluates to false the case label inside the body of the true branch renders it live, i.e., the statement printf("1"); is not dead code.

Another interesting point is that the clause-1 of the loop as well as the controlling expression must not be executed, if case 2 is jumped to. Thus, it is crucial that variable i is initialized upfront.

A further oddity is that although case 1 has no break statement and therefore falls through, it “jumps” over case 2 and continues at case 3 because case 1 is contained in the true branch and case 2 is contained in the false branch of the if statement.

Thus we have the following console output produced by the respective function calls:
```
foo(0)   -->    023
foo(1)   -->    13
foo(2)   -->    223
```
A famous real world example of a mixed loop and switch statement is termed Duff's device.
Consider the following function where the type of parameter x as well as of local variable y is an array of 42 integers.
```
bool foo(int x[42]) {
    int y[42];
    return sizeof(x) == sizeof(y);
}
```
The return value of function foo equals

true

false
Any parameter of type “array of T” is adjusted to a “pointer to T”. Thus the example is equivalent to the following:
```
bool foo(int *x) {
    int y[42];
    return sizeof(x) == sizeof(y);
}
```
For sizeof(y) we have that it equals 42 * sizeof(int). In general, the size of an object pointer does not equal 42 times the size of an integer. Thus, sizeof(x) == sizeof(y) evaluates to false in the general case.

Have a look at this post for a detailed discussion.
Assume that a compilation unit only consists of the definition of function foo and nothing else.
```
void foo(void) {
    bar(42);
}
```
Inside of function foo another function bar is called for which no declaration is given.

Code does not compile

Code compiles and is legal if bar is a unary function and the type of the parameter is a short

Code compiles and is legal if bar is a unary function and the type of the parameter is a int

Code compiles and is legal if bar is a unary function and the type of the parameter is a long

The code compiles since in C implicit functions are allowed—in contrast to C++ where this is a compile-time error.

Although integer 42 is guaranteed to be representable by all integer types—including all character types—the only legal type for the parameter is int. This is the case since no function declaration for bar is given and therefore the integer argument promotions are applied (see C11 § 6.5.2.2 Function calls ¶ 6) which means that number 42 is represented by an int. Thus if type of function bar is not compatible with T (*)(int) for some return type T, then the example invokes undefined behavior.
Consider the following code snippet:
```
struct X { int a[5]; } f(void);
int *p = f().a;
printf("%p\n", (void *)p);
```
According to one of the following three standards the code invokes undefined behavior. Which one?

C90

C99

C11
The lifetime of certain objects has been reduced in C11. In the example, the object returned by the function call is only alive until the right-hand side is evaluated in C11 whereas in C99 it is alive until the enclosing block ends. Referring to an object outside its lifetime invokes undefined behavior.

An example which invokes undefined behavior in C99, too, is given in the following:
```
struct X { int a[5]; } f(void);
int *p;
{ p = f().a; }
printf("%p\n", (void *)p);
```
The lifetime of an object with automatic storage duration is bounded to its nearest enclosing block in C99. Thus in line 4 we refer to an object which is not live anymore resulting in undefined behavior.

C11 § 6.2.4 Storage durations of objects ¶ 2

[…] If an object is referred to outside of its lifetime, the behavior is undefined. […]

The lifetime of an object is the portion of program execution during which storage is guaranteed to be reserved for it. An object exists, has a constant address,³³⁾ and retains its last-stored value throughout its lifetime.³⁴⁾ If an object is referred to outside of its lifetime, the behavior is undefined. The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime.

33) The term “constant address” means that two pointers to the object constructed at possibly different times will compare equal. The address may be different during two different executions of the same program.
34) In the case of a volatile object, the last store need not be explicit in the program.

The following paragraph is new and is the reason why the example invokes undefined behavior in C11.

C11 § 6.2.4 Storage durations of objects ¶ 8

[…] Its lifetime ends when the evaluation of the containing full expression or full declarator ends. […]

A non-lvalue expression with structure or union type, where the structure or union contains a member with array type (including, recursively, members of all contained structures and unions) refers to an object with automatic storage duration and temporary lifetime.³⁶⁾ Its lifetime begins when the expression is evaluated and its initial value is the value of the expression. Its lifetime ends when the evaluation of the containing full expression or full declarator ends. Any attempt to modify an object with temporary lifetime results in undefined behavior.

36) The address of such an object is taken implicitly when an array member is accessed.

For further discussion have a look at N1285 from which the code snippet was taken.

Score

You answered 0 out of 0 questions correctly!

C Programming Language Quiz

C17 § 6.4.4.1 Integer constants ¶ 5

C17 § 6.9.1 Function definitions ¶ 12

C++98 § 6.6.3 The return statement ¶ 2

C17 § 6.2.2 Linkages of identifiers ¶ 4

C11 § 6.7.6.3 Function declarators (including prototypes) ¶ 15

C17 § 6.7.6.3 Function declarators (including prototypes) ¶ 5

C11 § 6.2.5 Types ¶ 19

C11 § 6.3.2.1 Lvalues, arrays, and function designators ¶ 1

C11 § 6.3.2.1 Lvalues, arrays, and function designators ¶ 2

C11 § 6.6 Constant expressions ¶ 6

C11 § 6.7.6.2 Array declarators ¶ 4

C11 § 6.7.6.2 Array declarators ¶ 2

C11 § 6.2.4 Storage durations of objects ¶ 2

C11 § 6.2.4 Storage durations of objects ¶ 8

Score

C++98 § 6.6.3 The `return` statement ¶ 2