Am 09.10.23 um 18:35 schrieb Junio C Hamano: > René Scharfe <l.s.r@xxxxxx> 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é
