Re: Undefined behaviour in C23

Keith Thompson <Keith.S.Thompson+u@gmail.com>
Thu, 21 Aug 2025 12:53:49 -0700

          From comp.compilers

Related articles
Undefined behaviour in C23 mwardgkc@gmail.com (Martin Ward) (2025-08-20)
Re: Undefined behaviour in C23 643-408-1753@kylheku.com (Kaz Kylheku) (2025-08-20)
Re: Undefined behaviour in C23 anton@mips.complang.tuwien.ac.at (2025-08-21)
Re: Undefined behaviour in C23 david.brown@hesbynett.no (David Brown) (2025-08-21)
Re: Undefined behaviour in C23 mwardgkc@gmail.com (Martin Ward) (2025-08-21)
Re: Undefined behaviour in C23 Keith.S.Thompson+u@gmail.com (Keith Thompson) (2025-08-21)
Re: Undefined behaviour in C23 david.brown@hesbynett.no (David Brown) (2025-08-22)
Re: Undefined behaviour in C23 david.brown@hesbynett.no (David Brown) (2025-08-22)
Re: Undefined behaviour in C23 anton@mips.complang.tuwien.ac.at (2025-08-22)
Re: Undefined behaviour in C23 Keith.S.Thompson+u@gmail.com (Keith Thompson) (2025-08-22)
Re: Undefined behaviour in C23 david.brown@hesbynett.no (David Brown) (2025-08-23)
Re: Undefined behaviour in C23 antispam@fricas.org (2025-08-23)
[6 later articles]
| List of all articles for this month |
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.compilers
Date: Thu, 21 Aug 2025 12:53:49 -0700
Organization: Compilers Central
References: 25-08-002 25-08-003 25-08-005
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="58180"; mail-complaints-to="abuse@iecc.com"
Keywords: C, standards
Posted-Date: 21 Aug 2025 18:06:06 EDT

David Brown <david.brown@hesbynett.no> writes:
[...]
> 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.


I don't see an inconsistency.


A C program that includes a non-standard header that's not part of
the program (e.g., `#include <windows.h>`) and calls a function
declared in that header has undefined behavior as far as the C
standard is concerned. The program could be compiled in a conforming
environment that has its own <windows.h> header with a declaration
for different implementation of the same name.


That's undefined behavior under both the section 3 definition (use
of a nonportable program construct) and the section 4 definition
(the omission of any explicit definition of behavior).


[...]


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


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.


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


Post a followup to this message

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