On Tue, Feb 20, 2018 at 02:18:28PM -0800, Linus Torvalds wrote:
> On Tue, Feb 20, 2018 at 2:00 PM, Luc Van Oostenryck
> <luc.vanoostenryck@xxxxxxxxx> wrote:
> >
> > One detail about the syntax: my understanding of the attribute
> > syntax is that in:
> > typedef __bitwise enum foobar { FOO, BAR, } my_t;
> > which is essentially the same as:
> > enum foobar { FOO, BAR, };
> > typedef __bitwise enum foobar my_t;
> > the attribute relate to the typedef/my_t and not to the enum type.
>
> You are correct, and I didn't think of that wrinkle.
>
> And it's a fundamental wrinkle. A big part of the __bitwise thing
> really is that it creates a private type for each typedef, which is
> important for things like "big-endian u32".
>
> Now, arguably the typedef that actually is part of the definition of
> the type could be special,
I'm not 100% sure I understand the problem (if problem there is).
For the typedef, yes it's how it's used for __le32 or gfp_t because
we want to combine __bitwise with int to create a new, distinct type.
But here, we don't care about the typedef because we don't need one
since we're creating a new, distinct type anyway: the enum itself.
So I think that 'enum __bitwise foobar { FOO = 1, };' should be
a restricted type and should behave as Matthew would like.
Of course, 'typedef enum __bitwise { FOO = 1, } my_t' shoudl work
as well, being just a new name for a restricted anonymous enum.
-- 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
