C: The Dark Corners

From The C Programming Language:

The order in which function arguments are evaluated is unspecified, so the statement printf(“%d %d\n”, ++n, power(2, n)); can produce different results with different compilers, depending on whether n is incremented before power is called.

Thus it is good practice to avoid expressions in function calls.

Arrays are not pointers! There is a small number of cases when they behave differently. The following test is true:

array[0] == *array

From the C standard:

Except when it is the operand of the sizeof operator, the _Alignof operator, or the unary & operator, or is a string literal used to initialize an array, an expression that has type “array of type” is converted to an expression with type “pointer to type” that points to the initial element of the array object and is not an lvalue. If the array object has register storage class, the behavior is undefined.

Numbers are automatically upcast in function calls. Compare

unsigned char a = 255;
a++;
printf("%d\n", a);

and

unsigned char a = 255;
printf("%d\n", a+1);

There is no loss of information during an upcast, except for the char type. C does not specify whether a char should be signed. Thus signed or unsigned should be used to ensure portability.

From The C Programming Language, section 2.7:

Conversion rules are more complicated when unsigned operands are involved. The problem is that comparisons between signed and unsigned values are machine-dependent, because they depend on the sizes of the various integer types. For example, suppose that int is 16 bits and long is 32 bits. Then -1L < 1U, because 1U, which is an int, is promoted to a signed long. But -1L > 1UL, because -1L is promoted to unsigned long and thus appears to be a large positive number.

See appendix A6 in the book for more implicit conversion rules.

Be wary of the difference between a logical shift and an arithmetic shift. See this Wikipedia article for more details. Note that it only matters for right shifting.

The C behaviour is architecture-dependent for signed numbers.

In C99, the result of a modulo operation has the sign of the dividend:

printf("-5 % 2 = %d\n", -5 % 2);
printf("5 % -2 = %d\n", 5 % -2);

To test whether an integer is odd, you must compare to 0, not 1. Otherwise, the result will be incorrect when the dividend is negative.

if (n % 2 == 1) // WRONG!
if (n % 2 != 0) // Correct.

The choice for operator precedence in C can be counter-intuitive at times. The expression a & b == 7 is parsed as a & (b == 7).

See this Wikipedia article for more details.

When a text file is open in text-mode, (e.g. using the "r" option), POSIX specifies that the "b" option is ignored. Some non-POSIX operating systems, however, may try to be too smart. They will expect a “standard” end-of-line, such as \r\n. Which will obviously produce unexpected results on files with \n line breaks. The "b" option does not harm and helps for portability.

Pre-declarations can appear any number of times in C. They can appear only once in C++, or the compiler will complain about double definitions of globals:

#include <stdio.h>

int global;
int global;
int global = 3;

void change() {
    global = 17;
}

int main() {
    printf("%d\n", global);
    change();
    printf("%d\n", global);
    return 0;
}

In C, it will display the following:

3
17

It is not safe to assume that pointer arithmetic results in any integral type. Some architectures may have memory addresses indexed over 64-bit values, while using data over 32 bits. This behavior can be controlled from stdlib.h. For example, a pointer difference is stored as a type ptrdiff_t.

With GCC, sizeof(void) == 1 is true. This is non standard, but the behaviour is not clearly specified either. Using -pedantic will output a warning.

Do not expect the memory layout in structures to be as the code describes it: the compiler is free to pad some memory for optimization purposes.

This proves dangerous when serializing data. Use the offsetof macro to get the real offset of each structure member.

struct {char a; int b;} foo;
struct {char a; char b;} bar;

printf("sizeof foo == %zu\n", sizeof foo);
printf("&foo == %p\n", &foo);
printf("&foo.a == %p\n", &foo.a);
printf("&foo.b == %p\n", &foo.b);

printf("sizeof bar == %zu\n", sizeof bar);
printf("&bar == %p\n", &bar);
printf("&bar.a == %p\n", &bar.a);
printf("&bar.b == %p\n", &bar.b);

Compiling a header file may yield an unexpected result: some compilers such as GCC will recognize the extension and act accordingly. In that case, building a header will not result in an executable, but in a precompiled header, that is, an optimization for large headers.

If you want to force or prevent the build of precompiled headers, GCC allows for specifying the input language:

# The .xml file will be seen as a C header file.
gcc -x c-header myfile.xml
# The .h file will be compiled into an executable.
gcc -x c myfile.h

The numerous dark corners of C require some getting used to. It is helpful and good practice to make heavy use of your compiler’s warning flags, together with some fine “lint” tools.

• BSD/GNU man pages
• The C Programming Language, D. Ritchie & B. Kernighan
• Draft of the C standard
• Wikipedia/Arithmetic shift
• Wikipedia/Operator precedence
• Wikipedia/Type conversion
• Better variadic functions for C
• The C Library Reference Guide