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

From: Patrick Steinhardt <[email-masked]>
Date: Wed, 16 Apr 2025 12:28:01 +0200

On Tue, Apr 15, 2025 at 09:59:12AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <[email-masked]> 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