|Undefined behaviour, was: for or against equality email@example.com (Martin Ward) (2022-01-07)|
|Re: Undefined behaviour, was: for or against equality firstname.lastname@example.org (David Brown) (2022-01-07)|
|Re: Undefined behaviour, was: for or against equality email@example.com (Spiros Bousbouras) (2022-01-08)|
|Re: Undefined behaviour, was: for or against equality firstname.lastname@example.org (2022-01-08)|
|Re: Undefined behaviour, was: for or against equality email@example.com (David Brown) (2022-01-09)|
|Re: Undefined behaviour, was: for or against equality firstname.lastname@example.org (Kaz Kylheku) (2022-01-11)|
|Re: Undefined behaviour, was: for or against equality email@example.com (George Neuner) (2022-01-11)|
|From:||Kaz Kylheku <firstname.lastname@example.org>|
|Date:||Tue, 11 Jan 2022 16:55:54 -0000 (UTC)|
|Organization:||A noiseless patient Spider|
|References:||<email@example.com> 22-01-016 22-01-018 <firstname.lastname@example.org> 22-01-029 22-01-033|
|Injection-Info:||gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="9819"; mail-complaints-to="email@example.com"|
|Posted-Date:||11 Jan 2022 13:07:32 EST|
On 2022-01-08, Anton Ertl <firstname.lastname@example.org> wrote:
> David Brown <email@example.com> writes:
>>Undefined behaviour, as far as language standards are concerned, are
>>omnipresent in programming - for all languages.
> Please prove this astounding assertion. My impression is that managed
> languages define everything, at least to some extent, and leave
> nothing undefined. If they allowed nasal demons, the appeal of
> managed languages would evaporate instantly.
The Lisp-like programming language Scheme has unspecified order of
argument evaluation. And you can stuff side effects into argument
expressions, like in C.
Its built-in imperative have undefined return values.
ANSI Common Lisp leaves the effects undefined of modifying literals,
just like C. ANSI Lisp code that perpetrates some kind of error is
safe only if compiled in safe mode; if you compile with reduced safety,
e.g. (declare (optimize (safety 0))), then error become undefined
behavior, including type errors. If you declare that some quantity is
a fixnum integer, and request safety 0 speed 3, and then it turns
out that it's other than an integer, woe to that code.
However, in these cases you're invoking the safety escape hatch;
it's not like C where you are shackled by chains of undefined behavior
which make themselves felt every time you squirm.
Return to the
Search the comp.compilers archives again.