On Tue, Feb 20, 2018 at 09:20:45AM -0800, Linus Torvalds wrote:
> On Tue, Feb 20, 2018 at 9:02 AM, Luc Van Oostenryck wrote:
> > On Tue, Feb 20, 2018 at 08:09:39AM -0800, Matthew Wilcox wrote:
> >>
> >> I have a feature request relating to bitwise and enums. The following
> >> does not work the way I would like it to:
> >>
> >> typedef __attribute__((bitwise)) enum {
> >> FOO,
> >> BAR,
> >> } my_t;
Hi,
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 (or more exactly, between an enum and its base type).
So you can write things like:
void foo(enum e1);
...
void foo(int a) { ... }
and so on, without any warnings.
It certainly defeats a lot of type checking related to enums.
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.
2a) I expect NIL, ONE & DUO to all have the same type:
the base type of 'enum e2' (or 'enum e2' itself but IIUC, that's
not what the standard says).
2b) I expect a warning (or an error) if the initializers are not all
type compatible.
Cheers,
-- 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
