Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' ) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )
Date
Msg-id 22259.1573010500@sss.pgh.pa.us
Whole thread Raw
In response to Re: Keep compiler silence (clang 10, implicit conversion from 'long'to 'double' )  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> On Wed, Nov 6, 2019 at 3:33 PM Yuya Watari <watari.yuya@gmail.com> wrote:
>> However, this behavior depends on the platform architecture. As you
>> have said, C language does not always follow IEEE-754. I think adding
>> explicit checking of NaN is necessary.

> I'm curious about this point.  C may not require IEEE 754 (for
> example, on current IBM mainframe and POWER hardware you can opt for
> IBM hex floats, and on some IBM platforms that is the default, and the
> C compiler isn't breaking any rules by doing that; the only other
> floating point format I've heard of is VAX format, long gone, but
> perhaps allowed by C).  But PostgreSQL effectively requires IEEE 754
> since commit 02ddd499322ab6f2f0d58692955dc9633c2150fc, right?

That commit presumes that floats follow the IEEE bitwise representation,
I think; but it's a long way from there to assuming that float comparisons
do something that is explicitly *not* promised by C99.  The C spec goes no
further than to state that comparisons on NaNs might raise an exception,
and that's already bad enough.  I believe that the assumption Yuya-san was
making about "comparisons on NaNs return false" is only guaranteed by C99
if you use the new-in-C99 macros isless(x, y) and so on, not if you write
x < y.

There's a separate discussion to be had here about whether
    !isnan(x) && !isnan(y) && x < y
is more or less efficient, or portable, than
    isless(x, y)
but I'm not really in any hurry to start using the latter macros.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: Should we make scary sounding, but actually routine, errors lessscary?
Next
From: Stephen Frost
Date:
Subject: Re: cost based vacuum (parallel)