Incorrect f64 -> u64 conversions about v HOT 5 OPEN

The generated C code as follow:

	// assert1: assert u64(-1) == 18446744073709551615 // this one passes
	if (!(((u64)(-1)) == 18446744073709551615U)) {}
    
	// assert2: assert f64(u64(-1)) == u64(-1) // this one passes
	if (!(((f64)(((u64)(-1)))) == ((u64)(-1)))) {}
    
	// assert3: assert u64(f64(u64(-1))) == f64(u64(-1)) // this one fails. u64(f64(u64(-1))) gives 0
    if (!(((u64)(((f64)(((u64)(-1)))))) == ((f64)(((u64)(-1)))))) {}
	
    // assert4: assert u64(math.pow(2, 63)) == math.pow(2, 63) // this one works
	f64 _t4 = math__pow(2, 63);
	if (!(((u64)(math__pow(2, 63))) == _t4)) {}
    
	// assert5: assert u64(math.pow(2, 63) + 1) != math.pow(2, 63) // this one fails, which can make sense due to low precision on the f64
    f64 _t6 = math__pow(2, 63);
	if (!(((u64)((f64)(math__pow(2, 63) + 1))) != _t6)) {}
	
	// assert6: assert u64(math.pow(2, 64)) != math.pow(2, 63)
	f64 _t8 = math__pow(2, 63);
	if (!(((u64)(math__pow(2, 64))) != _t8)) {}

compile with different compilers:

v . 
v . -cc gcc
v . -cc clang

As for different C compilers, some assertions does not pass,

1. tcc fail at assert3, assert5, assert6
2. gcc fail at assert5,
3. clang fail at assert3, assert5, assert6

According to this result, I think there are some undefined actions of C lang, so different compiler handle these different.

from v.

The second part of this discussion would be on the expected behavior of an explicit cast from f64 to u64. What should the value be if say the value of the f64 cannot be represented as an u64? C probably pulls it's usual "oh it's undefined and vendor specific". That is not a good platform for safe computations. Safe should be the default with an optional escape hatch like unsafe { ... } or similar.

Note that no floats can generally be represented as integers no matter the size due to signed zero, nan's, and inf's. A stdlib conversion function that returns a Result or unsafe { .. } feels like a step up from C.

Side note: Fortran gave some more careful though and offers four ways to cast a float to an int. They talk about just the regular normal floats.This is hairy stuff when left to intuition- users are going to be surprised in a bad way. https://stackoverflow.com/questions/40310299/convert-a-real-output-into-integer#40310677

from v.

assert f64(u64(-1)) == u64(-1) // this one passes

That is a problem. Implicit cast between int and float should not be allowed because u64 max overflows the 15 decimals that float 64-bit can represent accurately.

Edit: My point is this: This statement should not compile.

I am fine with:

assert u64(f64(u64(-1))) == u64(-1) // expected to fail

from v.

@hholst80 the cast overflows the 15 decimals that f64 can represent accurately, but the max value of f64 is much higher than the max value of u64, so it doesn't overflow the range of acceptable values. So I don't think it should fail by default, but maybe a compiler warning would be a better way to handle it, in addition to a safe cast method.
The problem is that casting u32 to f64 is safe, and u32 to u64 is also safe, so it can be difficult to determine whether the cast is safe at compile time.

from v.

I did a poll a few years back "what is the worst feature of C++" and the implicit cast came up as the absolute worst.

The only case I can come to terms with is a numeric literal. As long as it can be promoted without loss of precision as-is, I can accept it as useful shorthand notation. Eg. assert f64(1) == 1.0 should be ok. Rationale: 1 can be cast to a 1 as f64 and 1.0 literal can be interpreted as a f64 without loss of precision. The only difference between cast and the "interpretation" should be the flexibility of scope and target container for the source number.

Relying on "whatever C does" is closer to the Absolute worst than it's close to Optimal. C does not do much if anything worth copying for numerically safe computations. Given that C is the intermittent state there has to be compile time guards against insecure code that can break the user code in unexpected ways.

from v.