Re: Incorrect usage of strtol, atoi for non-numeric junk inputs

At Mon, 26 Jul 2021 15:01:35 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> On Sat, Jul 24, 2021 at 07:41:12PM +0900, Michael Paquier wrote:
> > I have looked at that over the last couple of days, and applied it
> > after some small fixes, including an indentation.
>
> One thing that we forgot here is the handling of trailing
> whitespaces. Attached is small patch to adjust that, with one
> positive and one negative tests.
>
> > The int64 and float
> > parts are extra types we could handle, but I have not looked yet at
> > how much benefits we'd get in those cases.
>
> I have looked at these two but there is really less benefits, so for
> now I am not planning to do more in this area. For float options,
> pg_basebackup --max-rate could be one target on top of the three set
> of options in pgbench, but it needs to handle units :(

Thanks for revising and committing! I'm fine with all of the recent
discussions on the committed part. Though I don't think it works for
"live" command line options, making the omitting policy symmetric
looks good. I see the same done in several similar use of strto[il].

The change in 020_pg_receivewal.pl results in a chain of four
successive failures, which is fine. But the last failure (#23) happens
for a bit dubious reason.

> Use of uninitialized value in pattern match (m//) at t/020_pg_receivewal.pl line 114.
> not ok 23 - one partial WAL segment is now completed

It might not be worth amending, but we don't need to use m/// there
and eq works fine.

020_pg_receivewal.pl: 114
- is($zlib_wals[0] =~ m/$partial_wals[0]/,
+ is($zlib_wals[0] eq $partial_wals[0],

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center