Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| From: | Martin Ward <martin@gkc.org.uk> |
| Newsgroups: | comp.compilers |
| Date: | Mon, 6 May 2019 13:25:36 +0100 |
| Organization: | Compilers Central |
| References: | 19-05-014 19-04-021 19-04-023 19-04-037 19-04-039 19-04-042 19-04-044 19-04-047 19-05-004 19-05-008 19-05-014 19-05-021 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="36158"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | standards, errors |
| Posted-Date: | 06 May 2019 10:45:44 EDT |
| In-Reply-To: | 19-05-021 |
On 03/05/19 16:23, David Brown wrote:
> There are lots of situations where behaviour is undefined, in /all/
> programming languages. The lower level and more efficient the language,
> the more such situations you get - but none are entirely free of
> undefined behaviour.
There are many language in which all behaviour is defined:
for example, Go has no undefined behaviour. Some behaviour
may be "unspecified" (eg it could do X, or could do Y,
but cannot do anything else).
There is no logical requirement for leaving any behaviour undefined:
other than laziness by the language designers, or an inability
to reach agreement on a suitable behaviour. I believe Java
also has no undefined behaviour.
> You can prefer that languages have "true" preconditions for some
> functions, but they certainly won't have it for all.
Preconditions are used in proofs of correctness and in
the specification of functions. In a correctness proof, you prove
that for any initial state satisfying the given precondition,
the program is guaranteed to terminate in a state which
satisfies the given postcondition. For built-in functions
and operations in a language definition there is no reason why
the precondition cannot be "true", or the language could
specify that an error message is returned or an exception raised
if the function's precondition is not met.
> I have regularly said that most unsigned overflows are also bugs,
> and that undefined behaviour there would also make sense.
This would appear to make it extremely difficult to implement
two's complement arithmetic in C: currently one can cast
the signed values to unsigned, calculate the result,
and cast back to signed. (Note however that negative numbers are not
guaranteed to be stored in two's complement format!)
How would you implement arithmetic MOD 2^32, MOD 2^64 or MOD 2^128
if unsigned overflow was undefined?
--
Martin
Dr Martin Ward | Email: martin@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Return to the
comp.compilers page.
Search the
comp.compilers archives again.