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é
