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

From Yuya Watari
Subject Re: Keep compiler silence (clang 10, implicit conversion from 'long'to 'double' )
Date
Msg-id CAJ2pMkYNr7GikazuN0yKjGsa=OFbA9RrTU0_fm8w_Onns1ZV6A@mail.gmail.com
Whole thread Raw
In response to Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Keep compiler silence (clang 10, implicit conversion from 'long'to 'double' )  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Hello Tom,

Thank you for replying.

On Wed, Nov 6, 2019 at 12:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Yuya Watari <watari.yuya@gmail.com> writes:
> > The added macro FLOAT8_FITS_IN_INT32() does not check NaN explicitly,
> > but it sufficiently handles the case.
>
> Really?  I don't think anything is guaranteed about how a NaN will
> compare when using C's non-NaN-aware comparison operators.
>
> My thought about this was to annotate the macros with a reminder
> to also check for NaN if there's any possibility that the value
> is NaN.

I agree with your opinion. Thank you for pointing it out.

If the platform satisfies IEEE-754 standard, all comparisons (except
for "not equals") between NaN and other floating values are "false".
[1] In this case, the proposed FLOAT8_FITS_IN_INT32() macro handles
NaN.

[1] https://en.wikipedia.org/wiki/NaN#Comparison_with_NaN

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 modified the patch and attached it.

Best regards,
Yuya Watari
NTT Software Innovation Center
watari.yuya@gmail.com

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pgbench - extend initialization phase control
Next
From: Andres Freund
Date:
Subject: Re: pgbench - refactor init functions with buffers