Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Yuya Watari <watari(dot)yuya(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )
Date: 2019-11-06 03:21:40
Message-ID: 22259.1573010500@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Wed, Nov 6, 2019 at 3:33 PM Yuya Watari <watari(dot)yuya(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2019-11-06 03:51:28 Re: cost based vacuum (parallel)
Previous Message Chapman Flack 2019-11-06 03:00:58 Re: Should we make scary sounding, but actually routine, errors less scary?