|Undefined behaviour, was: for or against equality firstname.lastname@example.org (Martin Ward) (2022-01-07)|
|Re: Undefined behaviour, was: for or against equality email@example.com (David Brown) (2022-01-07)|
|Re: Undefined behaviour, was: for or against equality firstname.lastname@example.org (Spiros Bousbouras) (2022-01-08)|
|Re: Undefined behaviour, was: for or against equality email@example.com (2022-01-08)|
|Re: Undefined behaviour, was: for or against equality firstname.lastname@example.org (David Brown) (2022-01-09)|
|Re: Undefined behaviour, was: for or against equality email@example.com (Kaz Kylheku) (2022-01-11)|
|Re: Undefined behaviour, was: for or against equality firstname.lastname@example.org (George Neuner) (2022-01-11)|
|From:||David Brown <email@example.com>|
|Date:||Sun, 9 Jan 2022 23:53:52 +0100|
|Organization:||A noiseless patient Spider|
|References:||<firstname.lastname@example.org> 22-01-016 22-01-018 <email@example.com> 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="48149"; mail-complaints-to="firstname.lastname@example.org"|
|Posted-Date:||09 Jan 2022 18:34:40 EST|
On 08/01/2022 18:52, Anton Ertl 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.
Certainly managed languages define far more than unmanaged languages.
But equally certainly, they do not define everything.
In Python, I can write :
x = flooble(123)
Nowhere in any part of the documentation for Python is a definition of
what the function "flooble" should do. Calling it is /undefined
behaviour/ as far as the language standards are concerned.
Certainly some aspects of calling it - such as the calling convention -
are defined. What should happen if the function does not exist is
defined. But the language and the standards do not define the behaviour
Being "undefined behaviour as far as the language standards are
concerned" does not mean you can get nasal daemons, it means that the
language standards do not say what will happen. When one says "Division
by 0 is undefined behaviour in C", that is what is meant - as a compiler
or a host OS could give you well-defined and predictable behaviour when
you attempt to divide by 0.
A managed language may put limits on the kind of effect of undefined
behaviour. In Python (at least, CPython), it is possible to call
externally defined functions in shared libraries - even if the Python
bytecode interpreter limits possible effects of pure Python code,
calling external functions gets around those limits. I suppose you
could have a more locked-down managed language that does not allow any
external code, and has additional tracking on things like data space
usage, time usage, and other resources to stop run-away code.
Within such a closed language, you could have defined behaviour for all
code, since any code run or functions called would be in the same
language and have their definitions clear to the interpreter.
Personally, I don't see minimising undefined behaviour as part of the
appeal of managed languages. I make as much effort not to divide by
zero or work with invalid references in my Python code as I do in my C
code - it doesn't much matter if the program stops with Python exception
or a crash. I use Python for the convenience of working with strings,
dictionaries, and other data structures with little concern for memory
management, for its libraries, and other high-level features.
vital that the effect of any code is limited. Code may have behaviour
that is undefined by the language standards, but it will be defined by
other parts of the code or by its environment (browser, built-in
the browser, it should never be able to launch nasal daemons.
Return to the
Search the comp.compilers archives again.