From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 20 Jun 2022 16:32:35 GMT
Subject: Re: [PATCH] grep: add --max-count command line option
Message-ID: <7b7a2876-f6fe-1234-813b-71ba94a00422@cs.ucla.edu>
In-Reply-To: <xy0kCdbtIjKb_GkXpHs7eeE8eWLbbct69_tVczBGS3CMnnnKTlTheaeNlH-RB1mMAfWThSTN6bMThsQ4lLtr0Ji6RwG3Nd52L1muiEqdtCU=@protonmail.com>

On 6/20/22 11:25, Carlos L. wrote:
> This does not work well with OPTION_INTEGER, since it assumes the value to be int-sized:
>
> parse-options.c:
>   219             *(int *)opt->value = strtol(arg, (char **)&s, 10);

OK, so parse-options messes up if the user specifies a count that does 
not fit in 'int'? Although that's a separate bug, let's not make things 
worse here; let's make the new count an 'int'.

In the long run parse-options should be changed to use strtoimax instead 
of strtol, and the corresponding integers should be changed to intmax_t, 
and the proper thing should be done if the string value does not fit 
into intmax_t. But this longer-run fix affects all integer-valued 
options, not just this one.


> I also wanted to avoid using signed int so both sides of the comparison with `count` in grep_source_1() have the same sign.

Such comparisons cannot misfire if both values are nonnegative, and that 
can easily be arranged here.