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

From: Yuya Watari <watari(dot)yuya(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Keep compiler silence (clang 10, implicit conversion from 'long' to 'double' )
Date: 2019-10-02 06:56:07
Message-ID: CAJ2pMkam=NNzzgSZZs+Y6UXVj=K7Pup8w2tOQw5v1OU+5KgX8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Horiguchi-san,

On Tue, Oct 1, 2019 at 3:41 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)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(dot)yuya(at)gmail(dot)com

Attachment Content-Type Size
test.c text/plain 1.2 KB
v3-keep-compiler-silence.patch application/octet-stream 2.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-10-02 06:58:12 Re: pg_wal/RECOVERYHISTORY file remains after archive recovery
Previous Message Peter Eisentraut 2019-10-02 05:30:43 Re: Revert back to standard AC_STRUCT_TIMEZONE Autoconf macro