On Sat, Mar 27, 2010 at 2:29 AM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
