Re: Undefined behaviour in C23

On 20/08/2025 20:33, Kaz Kylheku wrote:
> 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.
>


Under "4. Conformance", the C standards says :


"""
If a "shall" or "shall not" requirement that appears outside of a
constraint or runtime-constraint is violated, the behavior is undefined.
    Undefined behaviour is otherwise indicated in this International
Standard by the words "undefined behavior" or by the omission of any
explicit definition of behavior. There is no difference in emphasis
among these three; they all describe "behavior that is undefined".
"""


So no list could ever be complete here, since anything whose behaviour
is not defined in the C standards is undefined behaviour. I have
always found that slightly at odds with the definition under "3.
Terms, definitions, and symbols" of "behavior, upon use of a
nonportable or erroneous program construct or of erroneous data, for
which this International Standard imposes no requirements". In my
mind, things like externally defined functions (used correctly) could
be considered UB by the section 4 definitions but not by the section 3
definitions.


>
> 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.
>


Yes, indeed - though that is the "section 4" type of UB rather than
the "section 3" definition - erroneous code and data should of course
be avoided at all times.




People who think UB is a bad thing should spend a little time thinking
about the phrase "garbage in, garbage out". If you write nonsensical
code, or give sensible code nonsensical data, you can't expect sensible
results. This has been known since the dawn of programmable computers
(and comes from mathematics and the domains of functions):


"""
On two occasions I have been asked, – "Pray, Mr. Babbage, if you put
into the machine wrong figures, will the right answers come out?" ... I
am not able rightly to apprehend the kind of confusion of ideas that
could provoke such a question
"""




UB (both definitions) is an essential part of all programming languages
- after all, if you have a bug in your code, you have UB, and no
programming language has made it impossible to write bugs in your code.
C just has some things that are undefined in C but defined in some other
languages, and it is a bit more open and honest about UB than many
language definitions.

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