Re: Optimization techniques and undefined behavior

On 06/05/2019 14:25, Martin Ward wrote:
> 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).


If I write a function "square_root" in Go that takes a non-negative
input and returns its square root, then calling that function with a
negative input is undefined behaviour.


It does not matter if it always has the same effect - if the behaviour
has not been specified, it is undefined.


Extrapolate that to any other aspect of any language, library, function,
etc.


> 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.
>


See above.




It is certainly that case that many languages have /less/ undefined
behaviour than C. It is certainly the case that many languages define
the behaviour of particular things that are famously undefined in C,
such as signed integer overflow (in many cases, the definitions are
stupid and worse than useless - in other cases they may be useful but
are inefficient).


And it is certainly the case that less undefined behaviour can be useful
- C is not the best choice of language for many tasks.




>> 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.
>


Preconditions and postconditions are not just for proofs - they are
specifications for the functions, and you should understand them for any
operation or function you use.


Certainly for many built-in functions and operations, it is possible to
have a "true" precondition. But there /are/ reasons why you don't
always want that. Different languages have different purposes. Checks
and exceptions are not free. Some languages have checks and exceptions
built in to save the programmer the effort, others require them to be
written manually to give the programmer full control.


>> 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!)


Correct.


>
> How would you implement arithmetic MOD 2^32, MOD 2^64 or MOD 2^128
> if unsigned overflow was undefined?
>


When saying that undefined behaviour for unsigned overflow would make
sense and be useful, I have usually also elaborated by saying you would
need another method to get wrapping behaviour on the few occasions when
you need it. I should have included this here too.

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