From: Patrick Steinhardt <ps@pks•im>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org,
"John Paul Adrian Glaubitz" <glaubitz@physik•fu-berlin.de>,
"Todd Zullinger" <tmz@pobox•com>, "René Scharfe" <l.s.r@web•de>,
"SZEDER Gábor" <szeder.dev@gmail•com>,
"Derrick Stolee" <stolee@gmail•com>, "Jeff King" <peff@peff•net>
Subject: Re: [PATCH v2 2/5] parse-options: introduce precision handling for `OPTION_INTEGER`
Date: Wed, 16 Apr 2025 12:28:01 +0200 [thread overview]
Message-ID: <Z_-GMXZmlfQmSuy6@pks.im> (raw)
In-Reply-To: <xmqqecxtmkdb.fsf@gitster.g>
On Tue, Apr 15, 2025 at 09:59:12AM -0700, Junio C Hamano wrote:
> 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
next prev parent reply other threads:[~2025-04-16 10:28 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-01 15:01 [PATCH 0/5] parse-options: harden handling of integer values Patrick Steinhardt
2025-04-01 15:01 ` [PATCH 1/5] global: use designated initializers for options Patrick Steinhardt
2025-04-01 15:01 ` [PATCH 2/5] parse-options: introduce precision handling for `OPTION_INTEGER` Patrick Steinhardt
2025-04-01 18:47 ` René Scharfe
2025-04-15 10:26 ` Patrick Steinhardt
2025-04-01 15:01 ` [PATCH 3/5] parse-options: introduce precision handling for `OPTION_MAGNITUDE` Patrick Steinhardt
2025-04-01 15:01 ` [PATCH 4/5] parse-options: introduce `OPTION_UNSIGNED` Patrick Steinhardt
2025-04-01 15:01 ` [PATCH 5/5] parse-options: detect mismatches in integer signedness Patrick Steinhardt
2025-04-15 12:14 ` [PATCH v2 0/5] parse-options: harden handling of integer values Patrick Steinhardt
2025-04-15 12:14 ` [PATCH v2 1/5] global: use designated initializers for options Patrick Steinhardt
2025-04-15 12:14 ` [PATCH v2 2/5] parse-options: introduce precision handling for `OPTION_INTEGER` Patrick Steinhardt
2025-04-15 15:51 ` Phillip Wood
2025-04-16 10:28 ` Patrick Steinhardt
2025-04-15 16:59 ` Junio C Hamano
2025-04-16 10:28 ` Patrick Steinhardt [this message]
2025-04-15 12:14 ` [PATCH v2 3/5] parse-options: introduce precision handling for `OPTION_MAGNITUDE` Patrick Steinhardt
2025-04-15 12:14 ` [PATCH v2 4/5] parse-options: introduce `OPTION_UNSIGNED` Patrick Steinhardt
2025-04-15 15:52 ` Phillip Wood
2025-04-16 10:27 ` Patrick Steinhardt
2025-04-16 13:31 ` phillip.wood123
2025-04-15 17:38 ` René Scharfe
2025-04-16 10:28 ` Patrick Steinhardt
2025-04-15 12:14 ` [PATCH v2 5/5] parse-options: detect mismatches in integer signedness Patrick Steinhardt
2025-04-15 17:02 ` Junio C Hamano
2025-04-16 10:02 ` [PATCH v3 0/7] parse-options: harden handling of integer values Patrick Steinhardt
2025-04-16 10:02 ` [PATCH v3 1/7] global: use designated initializers for options Patrick Steinhardt
2025-04-16 10:02 ` [PATCH v3 2/7] parse-options: check for overflow when parsing integers Patrick Steinhardt
2025-04-16 10:02 ` [PATCH v3 3/7] parse-options: introduce precision handling for `OPTION_INTEGER` Patrick Steinhardt
2025-04-16 17:29 ` Junio C Hamano
2025-04-16 10:02 ` [PATCH v3 4/7] parse-options: introduce precision handling for `OPTION_MAGNITUDE` Patrick Steinhardt
2025-04-16 10:02 ` [PATCH v3 5/7] parse-options: introduce `OPTION_UNSIGNED` Patrick Steinhardt
2025-04-16 18:50 ` Junio C Hamano
2025-04-17 8:15 ` Patrick Steinhardt
2025-04-16 10:02 ` [PATCH v3 6/7] parse-options: detect mismatches in integer signedness Patrick Steinhardt
2025-04-16 10:02 ` [PATCH v3 7/7] parse-options: introduce bounded integer options Patrick Steinhardt
2025-04-16 19:19 ` Junio C Hamano
2025-04-17 8:14 ` Patrick Steinhardt
2025-04-17 10:49 ` [PATCH v4 0/7] parse-options: harden handling of integer values Patrick Steinhardt
2025-04-17 10:49 ` [PATCH v4 1/7] parse: fix off-by-one for minimum signed values Patrick Steinhardt
2025-04-17 10:49 ` [PATCH v4 2/7] global: use designated initializers for options Patrick Steinhardt
2025-04-17 10:49 ` [PATCH v4 3/7] parse-options: support unit factors in `OPT_INTEGER()` Patrick Steinhardt
2025-04-17 10:49 ` [PATCH v4 4/7] parse-options: rename `OPT_MAGNITUDE()` to `OPT_UNSIGNED()` Patrick Steinhardt
2025-04-17 15:17 ` Junio C Hamano
2025-04-17 10:49 ` [PATCH v4 5/7] parse-options: introduce precision handling for `OPTION_INTEGER` Patrick Steinhardt
2025-04-17 10:49 ` [PATCH v4 6/7] parse-options: introduce precision handling for `OPTION_UNSIGNED` Patrick Steinhardt
2025-04-17 10:49 ` [PATCH v4 7/7] parse-options: detect mismatches in integer signedness Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z_-GMXZmlfQmSuy6@pks.im \
--to=ps@pks$(echo .)im \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=glaubitz@physik$(echo .)fu-berlin.de \
--cc=l.s.r@web$(echo .)de \
--cc=peff@peff$(echo .)net \
--cc=stolee@gmail$(echo .)com \
--cc=szeder.dev@gmail$(echo .)com \
--cc=tmz@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox