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 CAJ2pMkam=NNzzgSZZs+Y6UXVj=K7Pup8w2tOQw5v1OU+5KgX8g@mail.gmail.com
Whole thread Raw
In response to Re: Keep compiler silence (clang 10, implicit conversion from'long' to 'double' )  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )
List pgsql-hackers
Horiguchi-san,

On Tue, Oct 1, 2019 at 3:41 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> I found a trick seems workable generically (*1). (2.0 *
> (PG_INT64_MAX/2 + 1)) will generate the value next to the
> PG_INT64_MAX based on some assumptions
> (*1). IS_DOUBLE_SAFE_IN_INT64() below would be able to check if
> the value can be converted into int64 safely or not.

Thanks for sharing a nice way of checking overflow. I tested your
IS_DOUBLE_SAFE_IN_INT64() macro in my environment by the simple code
(attached to this email) and confirmed that it appropriately handled
the overflow. However, further consideration is needed for different
architectures.

I attached the modified patch. In the patch, I placed the macro in
"src/include/c.h", but this may not be a good choice because c.h is
widely included from a lot of files. Do you have any good ideas about
its placement?

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

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Revert back to standard AC_STRUCT_TIMEZONE Autoconf macro
Next
From: Michael Paquier
Date:
Subject: Re: pg_wal/RECOVERYHISTORY file remains after archive recovery