On Thu, Sep 3, 2009 at 4:47 AM, Kamil Dudka<kdudka@xxxxxxxxxx> wrote: > 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 it is cleaner to have one single place to look for the ctype of an expression.We don't have to convert it to int type. I think most of the sparse code can deal with enum type any way. I don't like the dual personality of expressions. An other reason is that you increase the expression structure size for 32 bit system. Expression and symbol are the most common used structure. It take up a good portion of the sparse memory foot print. I want to keep them as lean as possible. > 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 don't see why it is hard to split. Can we just make the code which add new options and issue new warnings to a separate patch? We shouldn't need to reverse engineering the old behavior to do that. > > 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 :-) Yes I agree the test case is always useful. 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
