Re: Yet another fast GiST build

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> You get the same error with:
> select (float8 '1e+300')::float4;
> float.c:1204:11: runtime error: 1e+300 is outside the range of
> representable values of type 'float'
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior float.c:1204:11 in

> It boils down to casting a C double to float, when the value doesn't fit
> in float. I'm surprised that's undefined behavior, but I'm no C99
> lawyer. The code in dtof() expects it to yield Inf.

I think UBSan read C99 6.3.1.5:

[#2] When a double is demoted to float or a long double to
double or float, if the value being converted is outside the
range of values that can be represented, the behavior is
undefined.

and stopped reading at that point, which they should not have.
If you go on to read the portions around, particularly, <fenv.h>,
you get a different picture of affairs. If we're relying on IEEE
float semantics in other places, which we are, we're perfectly
entitled to assume that the cast will yield Inf (and a floating
point exception flag, which we ignore). I think the "undefined"
here is just meant to say that there's no single behavior promised
across all possible C implementations. They'd have been better to
write "implementation-defined", though.

> I'm inclined to shrug this off and say that the sanitizer is being
> over-zealous. Is there some compiler flag we should be setting, to tell
> it that we require specific behavior? Any other ideas?

If UBSan doesn't have a flag to tell it to assume IEEE math,
I'd say that makes it next door to worthless for our purposes.

regards, tom lane