Re: Sparse crash when mixing int and enum in ternary operator

[Christopher Li <sparse@chrisli.org>]

On Sat, Mar 27, 2010 at 2:29 AM, Josh Triplett <josh@joshtriplett.org> wrote:
>>     .type = (enum keyword) (KW_SPECIFIER | KW_SHORT),
>>     lookup_keyword(token->ident, (enum namespace) (NS_KEYWORD | NS_TYPEDEF));
>
> That looks wrong.  .type doesn't contain a value of type "enum keyword",
> it contains the bitwise or of such values, which won't represent a valid
> enum value.  Thus, .type should have an integral type, not an enum type.
> The same goes for the second parameter of lookup_keyword.

According to the new "strict enum" rules which don't allow enum type to accept
value other than the enum list above, that is right.

But I argue that this strict enum rules does not make sense, after this change,
the code don't not gain any thing. In fact, it looks worse.

Sparse use a loosely define enum namespace for member "namespace". It means
it has all this basic enum value, from NS_MACRO to NS_KEYWORD. In my mind,
all combination of this value consider enum namespace as well. It is
just that I can't
list all of them in the enum list.

Using enum namespace for member "namespace" has benefit here. It is clear that
which set of value it belongs to. E.g. if you assign SYM_NODE into "namespace"
member it *looks* is obvious wrong.

It also helps people understand which set of value belongs to
"namespace" member.
Make "namespace" a plain int, that message is lost. It become very
confusing for new comer
what value was allowed in this int type.

So back to my point. It seems making the enum more strict is just make up rules
and gain nothing in real life. It makes code looks worse just to make
strict enum type
happy.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html