undefined

points

[-]

I do, yes. I check that the compiler reports the desired properties and in cases where my code fails to compile because it does not I special case and manually test each property my code depends on. In my case that's primarily mantissa bit width for the sake of various utility functions that juggle raw FP bits.

Even for "regular" architectures this turns out to be important for FP data types. Long double is an f128 on Emscripten but an f80 on x86_64 Clang, where f128 is provided as __float128. The last time I updated my code (admittedly quite a while ago) Clang version 17 did not (yet?) implement std::numeric_limits support for f128.

Honestly there's no good reason not to test these sorts of assumptions when implementing low level utility functions because it's the sort of stuff you write once and then reuse everywhere forever.

by shakna1 days ago|

prev|

[-]

Okay, as the last wasn't obvious enough: C does not do IEEE 754 math.

It is _all_ non-IEEE 754 math.

That it isn't compliant is a compiler guarantee, in the current state of things.

You may as well have an `assert(1)`.

by eesmith1 days ago|

parent|

[-]

And as I wrote, "There's platform and there's platform."

I don't support the full range of platforms that C supports. I assume 8 bit chars. I assume good hardware support for 754. I assume the compiler's documentation is correct when it says it map "double" to "binary64" and uses native operations. I assume if someone else compiles my code with non-754 flags, like fused multiply and add, then it's not a problem I need to worry about.

For that matter, my code doesn't deal with NaNs or inf (other than input rejection tests) so I don't even need fully conformant 754.

by fc417fc8021 days ago|

parent|

[-]

So you don't test for it because your code doesn't use it. Which is fine, but says nothing about code which does depend on the relevant assumptions.

by eesmith1 days ago|

parent|

[-]

I say nothing about code which can support when char is 64-bit because my entire point was that my definition of "platform" is far more restrictive than C's, and apparently yours.

You wrote "I generally include various static asserts about basic platform assumptions."

I pointed out "There's platform and there's platform.", and mentioned that I assume POSIX.

So of course I don't test for CHAR_BIT as something other than 8.

If you want to support non-POSIX platform, go for it! But adding tests for every single one of the places where the C spec allows implementation defined behavior and where all the compilers I used have the same implementation defined behavior and have done so for years or even decades, seems quixotic to me so I'm not doing to do it.

And I doubt you have tests for every single one of those implementation-defined platform assumptions, because there are so many of them, and maintaining those tests when you don't have access to a platform with, say, 18-bit integers to test those tests, seems like it will end up with flawed tests.

by fc417fc80218 hours ago|

parent|

[-]

> maintaining those tests when you don't have access to a platform with, say, 18-bit integers to test those tests, seems like it will end up with flawed tests.

No? I don't over generalize for features I don't use. I test to confirm the presence of the assumptions that I depend on. I want my code to fail to compile if my assumptions don't hold.

I don't recall if I verify CHAR_BIT or not but it wouldn't surprise me if I did.

by shakna1 days ago|

parent|

prev|

[-]

I can test for some of those. So I can support a broader range of platforms, than just "works for me".

I can't support IEEE 754, so its simply irrelevant - so long as I know I cannot support it, and behaviour differs.