| 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] |
| 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 */
Return to the
comp.compilers page.
Search the
comp.compilers archives again.