| Related articles |
|---|
| [2 earlier articles] |
| 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) |
| Re: Undefined behaviour in C23 Keith.S.Thompson+u@gmail.com (Keith Thompson) (2025-08-23) |
| Re: Undefined behaviour in C23 jameskuyper@alumni.caltech.edu (James Kuyper) (2025-08-25) |
| Re: Undefined behaviour in C23 jameskuyper@alumni.caltech.edu (James Kuyper) (2025-08-26) |
| [3 later articles] |
| From: | anton@mips.complang.tuwien.ac.at |
| Newsgroups: | comp.compilers |
| Date: | Fri, 22 Aug 2025 17:16:48 +0000 |
| Organization: | Compilers Central |
| References: | 25-08-002 25-08-003 25-08-005 25-08-007 25-08-008 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="64657"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | C, standards |
| Posted-Date: | 22 Aug 2025 18:23:18 EDT |
David Brown <david.brown@hesbynett.no> writes:
>On 21/08/2025 21:53, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> 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.
>
>
>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.
Yes, Humpty Dumpty. Meanwhile, the rest of the world says that a
program exercises undefined behaviour when the *programming language*
specification does not define what the program does (or explicitly
undefines it), and calls programs incorrect (or, colloquially, buggy)
that do not behave as the *program* specification or requirements
demand; a buggy program may be defined according to the programming
language specification; e.g., I believe that the following program is
defined according to one of the C standards:
#include <stdio.h>
int main(void)
{
puts("B");
}
If the specification of the program is to print "A" followed by a
newline, the program is incorrect, even though its behaviour is
defined.
A correct program may be undefined according to the programming
language specification (see Kaz Kylheku's examples).
Which brings us to your claim:
>>> UB (both definitions) is an essential part of all programming languages
This is nonsense. If the programming language defines the behaviour
of all programs it accepts, and rejects all the others, it does not
have undefined behaviour. As an example, Java tries to live up to an
even higher standard (no implementation-dependent behaviour aka "write
once, run everywhere"), but I am not sure if it succeeds in that.
- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/
Return to the
comp.compilers page.
Search the
comp.compilers archives again.