Re: Undefined behaviour, was: for or against equality

David Brown <david.brown@hesbynett.no>
Sun, 9 Jan 2022 23:53:52 +0100

          From comp.compilers

Related articles
Undefined behaviour, was: for or against equality martin@gkc.org.uk (Martin Ward) (2022-01-07)
Re: Undefined behaviour, was: for or against equality david.brown@hesbynett.no (David Brown) (2022-01-07)
Re: Undefined behaviour, was: for or against equality spibou@gmail.com (Spiros Bousbouras) (2022-01-08)
Re: Undefined behaviour, was: for or against equality anton@mips.complang.tuwien.ac.at (2022-01-08)
Re: Undefined behaviour, was: for or against equality david.brown@hesbynett.no (David Brown) (2022-01-09)
Re: Undefined behaviour, was: for or against equality 480-992-1380@kylheku.com (Kaz Kylheku) (2022-01-11)
Re: Undefined behaviour, was: for or against equality gneuner2@comcast.net (George Neuner) (2022-01-11)
| List of all articles for this month |

From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.compilers
Date: Sun, 9 Jan 2022 23:53:52 +0100
Organization: A noiseless patient Spider
References: <17d70d74-1cf1-cc41-6b38-c0b307aeb35a@gkc.org.uk> 22-01-016 22-01-018 <7f4f52f2-49ee-9e80-1f03-c3fb9c74f574@gkc.org.uk> 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="abuse@iecc.com"
Keywords: standards
Posted-Date: 09 Jan 2022 18:34:40 EST
In-Reply-To: 22-01-033
Content-Language: en-GB

On 08/01/2022 18:52, Anton Ertl wrote:
> David Brown <david.brown@hesbynett.no> 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
of "flooble".




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.


When running unknown code - such as javascript from a website - it is
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
libraries, etc.). And while it may crash the javascript program or hang
the browser, it should never be able to launch nasal daemons.


Post a followup to this message

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