On 05/22/2018 10:09 AM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On 05/22/2018 04:11 AM, Kyotaro HORIGUCHI wrote:
>>> At Fri, 18 May 2018 14:02:39 -0400, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote in
<5a6d6de8-cff8-1ffb-946c-ccf381800ea1@2ndQuadrant.com>
>>>> One patch silences a warning from convutils.pl about the unportability
>>>> of the literal 0x100000000. We've run for many years without this
>>>> giving us a problem, so I think we can turn the warning off pretty
>>>> safely.
>>> It was introduced by aeed17d000 (in 2017). The history of the
>>> file is rather short. Over 32-bit values do not apperar as a
>>> character so there's no problem in ignoring the warning for now,
>>> but can't we use bigint to silence it instead?
>> It would impose an additional dependency. bigint isn't installed by
>> default on many systems AFAICT, so I think we'd need a better reason
>> than this to require it.
> I agree with not adding a dependency (although FWIW, bigint does seem
> to be there in my minimal perl setups). But can't we fix it like this:
>
> - elsif ($in < 0x100000000)
> + elsif ($in <= 0xffffffff)
>
> At least in a quick test here, "-cw" doesn't moan about 0xffffffff.
>
> For consistency, the other arms of the "if" should be adjusted
> similarly.
>
>
Yeah. I tested this on the oldest 32 but perls I could find, the msys
and activestate perls on the XP machine that runs frogmouth and friends.
Even though they both have an ivsize of 4, the arithmetic seems to work
properly. Perhaps they store larger numbers as doubles, which you should
be able to do exactly up to about 52 bit integers. The other 32 bit
machine I have is an Ubuntu 16.04 VM, but there the perl has an ivsize
of 8, so of course it does the right thing.
We don't normally use these scripts anyway, so I'll go with this
suggestion without further investigation.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
