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>,
"Phillip Wood" <phillip.wood123@gmail•com>
Subject: Re: [PATCH v3 7/7] parse-options: introduce bounded integer options
Date: Thu, 17 Apr 2025 10:14:33 +0200 [thread overview]
Message-ID: <aAC4UwjLBllfeDLV@pks.im> (raw)
In-Reply-To: <xmqqsem7hq2k.fsf@gitster.g>
On Wed, Apr 16, 2025 at 12:19:31PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks•im> writes:
>
> > In the preceding commits we have introduced integer precisions. The
> > precision merely tracks bounds of the underlying data types so that we
> > don't try to for example write a `size_t` into an `unsigned`, which
> > could otherwise cause out-of-bounds writes.
> >
> > Some options may have bounds that are stricter than the underlying data
> > type. Right now, users of any such options would have to manually verify
> > that the value passed to such an option is inside the expected bounds.
> > This is rather tedious, and it leads to code duplication across sites
> > that wish to perform such bounds checks.
> >
> > Introduce `OPT_*_BOUNDED()` options that alleviate this issue. Users
> > can optionally specify both a lower and upper bound, and if set we will
> > verify that the value passed by the user is in that range.
> >
> > Signed-off-by: Patrick Steinhardt <ps@pks•im>
> > ---
> > parse-options.c | 40 ++++++++++++++++++++++++++++-----
> > parse-options.h | 52 +++++++++++++++++++++++++++++++++++++++++++
> > t/helper/test-parse-options.c | 5 +++++
> > t/t0040-parse-options.sh | 33 +++++++++++++++++++++++++++
> > 4 files changed, 125 insertions(+), 5 deletions(-)
>
> It is certainly cute, but unless there are plenty of existing users
> that use OPT_INTEGER() and friends and perform bounds checks
> themselves, I am not sure if this can withstand YAGNI criticism.
> And this step being at the end of the series, plus the above
> diffstat, tells us that there aren't any existing users converted to
> use this new mechanism.
Yeah, that was also a bit of my feeling. I was on the lookout for
callsites, but I ultimately didn't find too many. Which is basically the
reason why I said that this patch is more of a PoC, and that I'm happy
to drop it again.
> OPT_INTEGER that wants to track percentage may want to say the value
> is between 0 and 100 (inclusive), but instead we take it bounded not
> to exceed 100, without lower bound. Without a real callsite, we
> cannot even tell if it is acceptable compromise for the sake of
> simplicity to forbid 0 as lower or upper bound, for example.
Yes, `0` meaning "default" is restricting us here. But my counter
argument is that a value that can only be between `0` and `100` should
use `OPT_UNSIGNED` in the first place, which allows us to achieve
exactly that.
Let's just drop this patch for now. It was only a PoC anyway, and we can
use it as inpiration if we ever see that this feature is something we
want.
Patrick
next prev parent reply other threads:[~2025-04-17 8:14 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
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 [this message]
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=aAC4UwjLBllfeDLV@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=phillip.wood123@gmail$(echo .)com \
--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