Re: Strange test failure when running with valgrind

[Oliver Heimlich]

John,

first we have an explicit conversion from double to uint64 (or int64). 
Second, in the assert statement we have an implicit conversion from 
uint64 (or int64) to double.

Beware: b cannot be represented exactly in double-precision.

From the C99 standard (§ 6.3.1.4):
(1)	When a finite value of real floating type is converted to an integer 
type ... the fractional part is discarded (i.e., the value is truncated 
toward zero).

(2)	When a value of integer type is converted to a real floating type, 
[...] If the value being converted is in the range of values that can be 
represented but cannot be represented exactly, the result is either the 
nearest higher or nearest lower representable value, chosen in an 
*implementation-defined manner*.

I am not sure, but maybe valgrid replaces parts of the C library with a 
custom implementation, which behaves differently compared to normal glibc.

Failing and passing the test would both be standard conforming to C99.

Am 07.01.2015 um 20:49 schrieb John W. Eaton:
> The following test, and a similar one with int64 instead of uint64,
> fails when running Octave with valgrind:
>
>    a = 1.9*2^61; b = uint64 (a); b++; assert (b > a);
>
> The test does not fail when Octave is running normally (without valgrind).
>
> Any ideas about why could that be?
>
> When the test fails, it appears that b == a, though b++ does appear to
> increment the initial value of b, and b appears to be the same value in
> both cases (with and without valgrind).
>
> jwe