From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | watari(dot)yuya(at)gmail(dot)com |
Cc: | andrew(at)tao11(dot)riddles(dot)org(dot)uk, tgl(at)sss(dot)pgh(dot)pa(dot)us, thomas(dot)munro(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' ) |
Date: | 2019-11-07 06:09:44 |
Message-ID: | 20191107.150944.889761811766014411.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 6 Nov 2019 13:56:46 +0900, Yuya Watari <watari(dot)yuya(at)gmail(dot)com> wrote in
> Hello Tom, Thomas, and Andrew,
>
> > Tom> That commit presumes that floats follow the IEEE bitwise
> > Tom> representation, I think;
> >
> > Correct. (It notably does _not_ make any assumptions about how floating
> > point arithmetic or comparisons work - all the computation is done in
> > integers.)
> >
> > Tom> but it's a long way from there to assuming that float comparisons
> > Tom> do something that is explicitly *not* promised by C99.
> >
> > I agree.
>
> Thank you for your comments. I agree that we should not assume
> anything that is not guaranteed in the language specification. The
> modified patch (attached in the previous e-mail) checks NaN explicitly
> if needed.
Mmm? See the bit in the patch cited below (v5).
+ /* Range check */
+ if (unlikely(!FLOAT8_FITS_IN_INT32(num)) || isnan(num))
If compiler doesn't any fancy, num is fed to an arithmetic before
checking if it is NaN. That seems have a chance of exception.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Sharma | 2019-11-07 06:15:35 | Re: tableam vs. TOAST |
Previous Message | Pavel Stehule | 2019-11-07 05:58:35 | Re: dropdb --force |