Re: [PATCH 2/2] parse-options: use and require int pointer for OPT_CMDMODE

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Sep 18, 2023, 19:48 UTC
Message-ID: <000ff1b9-e7a5-4dd6-bc61-4b6761f66997@gmail.com>
In-Reply-To: <xmqqedivl832.fsf@gitster.g>

On 18/09/2023 18:11, Junio C Hamano wrote:

Show 12 quoted lines

>> Then in builtin/am.c at the top level we'd add
>>
>> MAKE_CMDMODE_SETTER(resume_type)
>>
>> and change the option definitions to look like
>>
>> OPT_CMDMODE(0, "continue", resume_type, &resume.mode, ...)
> 
> Yup, that is ergonomic and corrects "The shape of a particular enum
> may not match 'int'" issue nicely.  I do not know how severe the
> problem is that it is not quite type safe that we cannot enforce
> resume_type is the same as typeof(resume.mode) here, though.

We could use gcc's __builtin_types_compatible_p() if we're prepared to have two definitions of OPT_CMDMODE_F

#if defined(__GNUC__)
#define OPT_CMDMODE_F(s, l, n, v, h, i, f) { \
	...
	.defval (i) + \
		BUILD_ASSERT_OR_ZERO(__builtin_types_compatible_p(enum n, 
__typeof__(v))), \
}
#else
#define OPT_CMDMODE_F(s, l, n, v, h, i, f) { \
	...
	.defval (i), \
}
#endif

Best Wishes

Phillip