On Mon, Apr 16, 2018 at 1:48 AM, Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>
> I'm back on this topic but I'm seeing some oddities related to enums
> and I'm wondering if these are desired behaviour or just bugs or
> implementation flaws. Any clarification is very welcome.
>
> 1) type_difference() doesn't make a distinction between an enum and an
> int
That's just being lazy - in standard C (ie the absence of __bitwise),
enums work like int for all type checking.
So that whole "just peel off the enum type, look at the base type" is
just because of the normal C semantics. Maybe
Note that it is wrong *even for standard C*.
You can pass a "pointer to enum", and the lazy cherck in
type_difference() means that it thinks it's the same as "pointer to
int".
So the type_difference handling is actively wrong, and much too
permissive, but nobody cared enough to ever get it right.
Sorry.
> 2) if you define an enum like:
> enum e2 {
> NIL = 0,
> ONE = 1U,
> DUO = 2LL,
> };
>
> then the type of NIL, ONE & DUO is int, unsigned int and long long.
Yeah, I think that's wrong too, they should all be 'enum e2' as you say.
And I think it comes from the same thing above: we never were very
careful with enums. Sparse tried to be careful with types, but it was
always mainly about other things (ie notably the whole "__user"
annotation), and enums were more of a "make it not complain".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
