On Thu September 3 2009 11:42:30 Christopher Li wrote: > Can we just set the expression->ctype to the enum type > instead of adding the *enum_type? I think the current expr->ctype > can be reached from enum_type->ctype.base_type any way. > In other words, we do care about expression is enum type vs int type > in this patch. > > After the type evaluation(and possible warning), we can convert that > enum type back to the base int type because the back end does not > care about enum. Do you want to store the correct enum type to expression->ctype and overwrite it later with some integral type? What's the advantage of this approach? (instead of preserving ABI which is already changed to 0.4.1). I don't think the information about type for enum constant is useful only for issuing warnings like this. Some SPARSE clients might also need such information. > I think fixing the regression should be a separate patch from > the this patch which adding new feature. It is easier to review > as well. Sure if anybody is able to split it... Unfortunately we have no reference for the "original" behavior of -Wmismatch-enum. I didn't found it documented anywhere and the "test-case" from the referred commit is not really useful as a test-case. I have not enough time for reverse engineering... I think the tests included in the patch have good enough coverage to prevent you from a future regression and it sounds more important to me than documenting previous regressions :-) Kamil -- 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
