Re: [PATCH v2 2/5] parse-options: introduce precision handling for `OPTION_INTEGER`

From: Patrick Steinhardt <ps@pks.im>
Date: Apr 16, 2025, 10:28 UTC
Message-ID: <Z_-GMXZmlfQmSuy6@pks.im>
In-Reply-To: <xmqqecxtmkdb.fsf@gitster.g>

On Tue, Apr 15, 2025 at 09:59:12AM -0700, Junio C Hamano wrote:

Show 23 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
> 
> > diff --git a/parse-options.h b/parse-options.h
> > index 997ffbee805..8d5f9c95f9c 100644
> > --- a/parse-options.h
> > +++ b/parse-options.h
> > @@ -92,6 +92,10 @@ typedef int parse_opt_subcommand_fn(int argc, const char **argv,
> >   * `value`::
> >   *   stores pointers to the values to be filled.
> >   *
> > + * `precision`::
> > + *   precision of the integer pointed to by `value`. Should typically be its
> > + *   `sizeof()`.
> 
> The fact of the integer allowing to store up to 16-bit vs 32-bit, is
> that "precision"?  "My --size option runs up to 200,000, what value
> should I set it to?" is a natural question the readers of this
> sentence would have in their mind, if we call it "range" or
> something (which might not be a bad thing to have, but that is
> totally outside the theme of this topic).
> 
> In any case, include a phrase "number of bytes" somewhere in the
> description to make it clear what unit we are counting.

Makes sense, will dot.

> Are their common use case where this number is *not* its sizeof()
> already in the codebase?

Yeah, this is something that I thought about quite a lot. I think the "precision" and "range" are somewhat orthogonal to one another:

  - The range specifies which values are accepted.

  - The precision specifies the underlying width of the type.

Right now I only handle the latter, but the next step here would be to also start handling the former. But even if we also started to handle the range there is merit in tracking both, as there will be usecases where the range would fit into a smaller underlying type, but due to other reasons one still wants to use the bigger underlying type.

The next step would thus be to introduce such an optional range so that options can restrict it independent of the precision. "parse-options.c" would in that case learn to have a run-time assert that the specified range fits into the given precision (and signedness). And obviously, it would of course also learn to return an error if the value passed by the user exceeds the range.

Patrick