What are the common undefined/unspecified behavior for C that you run into? [closed]

Answer 1

My personal favourite undefined behaviour is that if a non-empty source file doesn't end in a newline, behaviour is undefined.

I suspect it's true though that no compiler I will ever see has treated a source file differently according to whether or not it is newline terminated, other than to emit a warning. So it's not really something that will surprise unaware programmers, other than that they might be surprised by the warning.

So for genuine portability issues (which mostly are implementation-dependent rather than unspecified or undefined, but I think that falls into the spirit of the question):

• char is not necessarily (un)signed.
• int can be any size from 16 bits.
• floats are not necessarily IEEE-formatted or conformant.
• integer types are not necessarily two's complement, and integer arithmetic overflow causes undefined behaviour (modern hardware won't crash, but some compiler optimizations will result in behavior different from wraparound even though that's what the hardware does. For example if (x+1 < x) may be optimized as always false when x has signed type: see -fstrict-overflow option in GCC).
• "/", "." and ".." in a #include have no defined meaning and can be treated differently by different compilers (this does actually vary, and if it goes wrong it will ruin your day).

Really serious ones that can be surprising even on the platform you developed on, because behaviour is only partially undefined / unspecified:

• POSIX threading and the ANSI memory model. Concurrent access to memory is not as well defined as novices think. volatile doesn't do what novices think. Order of memory accesses is not as well defined as novices think. Accesses can be moved across memory barriers in certain directions. Memory cache coherency is not required.

• Profiling code is not as easy as you think. If your test loop has no effect, the compiler can remove part or all of it. inline has no defined effect.

And, as I think Nils mentioned in passing:

• VIOLATING THE STRICT ALIASING RULE.

Answer 2

The clang developers posted some great examples a while back, in a post every C programmer should read. Some interesting ones not mentioned before:

• Signed integer overflow - no it's not ok to wrap a signed variable past its max.
• Dereferencing a NULL Pointer - yes this is undefined, and might be ignored, see part 2 of the link.

Answer 3

I can't count the number of times I've corrected printf format specifiers to match their argument. Any mismatch is undefined behavior.

• No, you must not pass an int (or long) to %x - an unsigned int is required
• No, you must not pass an unsigned int to %d - an int is required
• No, you must not pass a size_t to %u or %d - use %zu
• No, you must not print a pointer with %d or %x - use %p and cast to a void *

Answer 4

Another issue I encountered (which is defined, but definitely unexpected).

char is evil.

• signed or unsigned depending on what the compiler feels
• not mandated as 8 bits

Answer 5

Dividing something by a pointer to something. Just won't compile for some reason... :-)

result = x/*y;