Re: Undefined behavior sanitizing with Clang

[Mike Miller]

On Sat, Aug 10, 2013 at 13:53:39 +0200, Philipp Kutin wrote:
> No. It's not that literals and variables are treated any differently,
> it's that converting a double whose truncated value can't be
> represented in the target integer type is *undefined behavior*, and as
> a consequence, our sample programs are completely devoid of meaning
> from the start. A compiler is not obliged to produce any particular
> code for them at all.

True, I wasn't trying to assert that the behavior is defined, although
it probably came off that way. Just that the sample program you came up
with doesn't appear to be handled by the particular compilers we are
looking at in the same way as the suspect code in Octave :)

I agree with your digging into and helping to eliminate UB code in
Octave and thanks for your efforts.

> I see. Then I guess the most logical way to procees is to reduce each
> element modulo 2^32, somewhat like this pseudo-code ("elem" is a
> double):
> 
> if (isnan (elem))
>     elem = <arbitrary-but-fixed>;
> else
> {
>     elem = fmod(elem, 4294967296.0)  // UINT32_MAX+1.0
>     // fmod() is the remainder on division that rounds toward 0, i.e.
> its sign follows the numerator.
>     // we want a number in [0 .. UINT32_MAX+1.0) though.
>     if (elem < 0)
>         elem = elem += UINT32_MAX+1.0;
> }
> 
> Because currently, the behavior may only be called "deterministic" (in
> big quotes) for a particular build, if the compiler was well-meaning
> on that day.

Right, understand.

Also, to be clear, I wasn't suggesting that Matlab's rand does accept
negative numbers, but *if* it does, then Octave should also. I'm not
sure whether it does or not, someone else will have to confirm.

-- 
mike