On Mon, Apr 16, 2018 at 08:27:43AM -0700, Linus Torvalds wrote:
> On Mon, Apr 16, 2018 at 1:48 AM, Luc Van Oostenryck 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.
OK, thanks for the info.
I wanted to be sure that it wasn't so on purpose because the code
in type_difference() looks as if it could have been so.
> > 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".
Yes, no problem. I'll look a this very soon.
Thanks again,
-- Luc
--
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
