Re: What's cooking in git.git (Oct 2023, #03; Fri, 6)

["René Scharfe" <l.s.r@web.de>]

Am 09.10.23 um 18:35 schrieb Junio C Hamano:
> René Scharfe <l.s.r@web.de> writes:
>
>> Am 07.10.23 um 10:20 schrieb Junio C Hamano:
>>> * rs/parse-options-value-int (2023-09-18) 2 commits
>>>  - parse-options: use and require int pointer for OPT_CMDMODE
>>>  - parse-options: add int value pointer to struct option
>>> ...
>> I don't mind removing this topic from seen for now; it's not ready, yet.
>
> After seeing the discussion moved to giving a more type safe enum
> support and then somehow convesation seemed to have petered out, I
> was wondering if we figured out the problem space enough to see an
> updated version with well defined scope and good problem
> description.

It's a simple idea with a broad scope: Replace void pointers or fortify
them by tracking type information across their use in order to get
compile time type checks for the entire code base.  Give developers the
basic guardrails they already have everywhere else also in generic code.

Adding such type checks is easy, but fixing all the places using
incompatible pointers is a lot of churn.  Option parsing, sorting and
many other callback functions would have to be fortified.  The
OPT_CMDMODE patches were a test balloon for a small subset of the void
space.  Extending them to cover more or even all of the int options may
give a better picture of the price for such a feature.

Will it uncover user-visible bugs?  So far it hasn't, not directly.
Perhaps ASan suffices and we don't need to care about exotic platforms
that would punish our type sins.

Dealing with the OPT_CMDMODE code prompted to me to come up with ways
to improve its error messages, though.  These patches took me
surprisingly long to prepare (plus my Git time is quite limited these
days).  I'll send them separately.

> I do not mind keeping it on 'seen', especially if
> these two early steps are not expected to change.  It is not like
> they are causing any maintenance burden.

The OPT_CMDMODE error message improvements change the code a lot and
conflict with these parse-options patches.  Please drop the latter and
let's discuss the former first, as their user-visible changes are more
tangible and useful.  I'll send an adjusted and perhaps bigger type
safety test balloon eventually.

René