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

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

Am 19.09.23 um 11:40 schrieb Oswald Buddenhagen:
> On Sat, Sep 09, 2023 at 11:14:20PM +0200, René Scharfe wrote:
>> Some uses of OPT_CMDMODE provide a pointer to an enum.  It is
>> dereferenced as an int pointer in parse-options.c::get_value().  These
>> two types are incompatible, though
>>
> s/are/may be/ - c.f. https://en.cppreference.com/w/c/language/enum

You're right.  Citing the relevant part: "Each enumerated type [...] is
compatible with one of: char, a signed integer type, or an unsigned
integer type [...]. It is implementation-defined which type is
compatible with any given enumerated type [...]."  So there's a chance
that the underlying type would be compatible by accident.

When we try a few combinations (https://godbolt.org/z/KvKcndY4Y),
Clang warns about incompatible pointers if we use a pointer to an enum
with only positive values as int pointer and about different signs if
use a pointer to an enum with negative values as in unsigned int
pointer and accepts the rest.  GCC accepts the same cases, but all its
warnings are about incompatible pointers.  This seems to be dependent
on the optimization level, though.  MSVC warns about all combinations.

>> -- the storage size of an enum can vary between platforms.
>>
> here's a completely different perspective:
> this is merely a theoretical problem, right? gcc for example won't
> actually use non-ints unless -fshort-enums is supplied. so how about
> simply adding a (configure) test to ensure that there is actually no
> problem, and calling it a day?

That would be an easy, but complex solution.  If the check is done
using -Wincompatible-pointer-types or equivalent then MSVC is out.  If
we base it on type size then we're making assumptions that I find hard
to justify.  Using the same type at both ends of the void and avoiding
compiler warnings that would have been issued if we'd cut out the
middle part is simpler overall.

René