Re: perl checking - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: perl checking
Date
Msg-id ed314d17-dded-80f3-68b4-2a6384ffc329@2ndQuadrant.com
Whole thread Raw
In response to Re: perl checking  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: perl checking  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

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>
>> These two small patches allow us to run "perl -cw" cleanly on all our
>> perl code.
>>
>>
>> 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 was a little optimistic about claiming that 'perl -cw' would run 
cleanly with these two patches - there's a little remediation that will 
be required in the src/msvc/tools directory. These patches at least let 
it run to completion.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Michail Nikolaev
Date:
Subject: Re: [WIP PATCH] Index scan offset optimisation using visibility map
Next
From: Robert Haas
Date:
Subject: Re: Fix for FETCH FIRST syntax problems