Re: Undefined behaviour in C23

comp.lang.c would probably be a better place for this discussion,
but cross-posting between moderated and unmoderated newsgroups is
likely to cause problems.


David Brown <david.brown@hesbynett.no> writes:
> On 21/08/2025 21:53, Keith Thompson wrote:
[...]
> If you declare and call a function "foo" that is written in fully
> portable C code, but not part of the current translation unit being
> compiled (perhaps it has been separately compiled or included in a
> library), then it would be UB by the section 4 definition (since the C
> standards don't say anything about what "foo" does, nor does your code).


If the translation unit that defined "foo" is part of your program, then
your code *does* define its behavior. Linking multiple translation
units into a program is specified by the C standard; it's translation
phase 8.


> But the code that calls "foo" is portable and not erroneous, so it is
> not UB by the section 3 definition.


If "foo" is defined by your program, either in the current
translation unit or in another one, the call is well defined
(assuming "foo" doesn't do something silly like dividing by zero).
If "foo" is defined outside your program, the C standard has nothing
to say about it. It could even be implemented in a language other
than C.


The *behavior* of such a call is not portable. (And the execution of
such a call is definitely undefined behavior if the visible declaration
is inconsistent with the definition.)


The section 3 definition of "undefined behavior" is a bit informal.
It's not clear what it means by "erroneous", for example. Section
4 is more precise, and states that UB can be indicated "by the
omission of any explicit definition of behavior" (in the standard).
The standard omits any definition of the behavior of foo().


[...]


> Add to that, the C standard has a specific term for features that are
> non-portable but not undefined behaviour - "implementation-defined
> behaviour". Code that relies on "int" being 32-bit is not portable, but
> it is not UB when compiled on implementations for which "int" /is/ 32-bit.


That's not what "implementation-defined behavior" means in C.
Cases of implementation-defined behavior are explicitly called out in
the standard, and an implementation must document how it treats each
instance of implementation-defined behavior. Each implementation
must document the range of int. There is no such requirement for
the behavior of "foo" defined in some non-standard header.


>> No, a bug in your code is not necessarily undefined behavior. It could
>> easily be code whose behavior is well defined by the language standard,
>> but that behavior isn't what the programmer intended.
>
> When I write code, /I/ define what the behaviour of the code should be.
> A bug in the code means it is not acting according to my definitions -
> it is UB. It may still be acting according to the definitions of the C
> abstract machine given in the C standards (you are correct there). Even
> if it has C-standard UB, it will still be acting according to the
> definitions of the target machine's instruction set. Behaviour is
> defined on multiple levels, only one of which is the C standard.


"Undefined behavior" is a technical term defined by the C standard.
It's not just behavior that is not defined. It is behavior that
is not defined *by the C standard*. If I write printf("goodbye\n")
when I meant to write printf("hello\n"), that's incorrect behavior,
but it's not undefined behavior.


--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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