Re: Optimization techniques and undefined behavior

On Tue, 7 May 2019 16:03:04 +0200, David Brown
<david.brown@hesbynett.no> wrote:


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


That is splitting a fine hair.




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


*You* specified the behavior by implementing the function. If you
want to argue that there will never be wide spread agreement on the
behavior, then ok ... but if you are want to argue semantics, then
nothing that can be implemented can truly be "undefined".


And if you really want to argue about "wide agreement", then language
standards don't qualify - most programmers do not actively *agree*
with the standard but simply choose to go along with it. For most the
"choice" is made either by necessity - e.g., a business requirement to
use the language - or simply by inertia or apathy [too big a deal to
switch to a more "agreeable" language].


One data point: I will use C or C++ because I'm paid to do so, not
because I like them or because I agree with the decisions made by
their standards committees.




Programming is NOT mathematics [or even mathematical in general] and
there is no reason other than sanity that computer code should have to
obey accepted physical or mathematical rules. And in fact, it
doesn't: if it did, we wouldn't be having arguments about signed vs
unsigned vs saturating vs wrap-around integers or how to deal with the
difference between real numbers and floating point arithmetic.




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


When I do, I come to a completely different conclusion.


YMMV,
George

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