Re: Undefined behaviour in C23

On 2025-08-20, Martin Ward <mwardgkc@gmail.com> wrote:
> In the SEI CERT C Soding Standards we read:
>
> "According to the C Standard, Annex J, J.2 [ISO/IEC 9899:2024],
> the behavior of a program is undefined in the circumstances outlined
> in the following table."
>
> The table has 221 numbered cases and can be found here:
>
><https://wiki.sei.cmu.edu/confluence/display/c/CC.%2BUndefined%2BBehavior>
>
> According to the C Standard Committee (paraphrasing) "You may eat
> from any tree in the garden of coding, except for any of the 221
> trees of undefined behaviour. If you eat from any of the 221 trees
> of undefined behaviour your program may die, either immediately or at
> some unspecified time in the future, or may do absolutely anything at
> any future time. You must study the Book of the Knowledge of Defined
> and Undefined (the 758 page C23 standard document) to learn exactly
> how to recognise each of the 221 trees of undefined behaviour.
> Please pay the cashier $250.00 to purchase a copy of the Book
> of the Knowledge of Defined and Undefined".


The list is incomplete.


For instance, the behavior is undefined when translation units are linked into a
program and contain the use of an external name that is neither defined by the
standard, nor by those translation units.


(Actual behavior may range from diagnosing an unresolved reference, to resolving
it to something in the implementation for which no requirements are given in the
standard.)


The behavior is undefined when #include directive is processed that resolves
neither to a standard header, nor to any of the files presented for processing
by the implementation.


(Actual behavior may be that the header doesn't resole to anything, which is a
constraint violation. Or it may resolve to something in the implementation which
replaces it with a sequence of tokens, for the nature of which ISO C imposes no
requirements.)


Any situation in the standard whereby we are not able to deduce the requirements
for a given program or construct is undefined behavior.


#include <windows.h> is undefined behavior.


fdopen(0, "r") is undefined behavior.


We can make a C impementation in which #include <windows.h> recursively deletes
the current directory, right there at at compile time, and that implementation
couldn't be called nonconforming because of that. The #include <windows.h>
construct can have all the consequences that are given in the definition of
undefined behavior: terminating translation or execution with or without a
diagnostic message, behaving unpredictably, or in a documented manner
characteristic of the implementation.


All platform specific headers and functions are effectively documented
extensions replacing undefined behavior, which another impelmentation could
neglect to define, or define arbitrarily (including in evil ways).


Once you grok the fact that almost real work in C takes place via undefined
behavior (very few programs are maximally portable and strictly conforming) you
stop sweating it.


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Return to the comp.compilers page.
Search the comp.compilers archives again.