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 |
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 |