On Sun, Oct 01, 2006 at 09:52:31AM -0700, Linus Torvalds wrote: > (Now, it's entirely possible that we warn so early that we can't > reasonably do this optimization until after we've already warned, but I've > been able to remove these kinds of warnings before, so I think it should > be possible to do it here too). > > I much prefer (if possible) the "make sparse so much smarter that it sees > that it's ok" approach over "let's add a magic special case". For example, > a lot of the work I did to make the lock acquire/release logic useful was > very much about teaching sparse to simplify code-flow rather than anything > else. > > But hey, maybe this case is too hard or nasty.. Hrm... The gut feeling: we mangle expression trees too much to be able to do that decently. We would have to carry "this might be le16"/"this might be be16"/"this might be foo_t" up *anyway*. Because what we see several nodes up is be16 | int. And even if we guess that it might be expanded 16bit, we _still_ need to know which 16bit it was. So you have to propagate that up and that's exactly what I'm doing. "Find how much we could narrow it" is a separate question; _that_ is best done by moving the casts down. But I would not mix that with type warnings. We _do_ mangle the tree a lot, so by the time we start walking down, we might have large chunks in a very inconvenient shape. The bottom line: your variant either requires to carry "which 16bit it might have been" along with the expression type (in which case it's exactly what I've done, modulo data representation), _OR_ it requires 3 passes - normal type evaluation + walking down trying to narrow the things down + walking up *again* trying to generate those postponed warnings. Because you won't be able to do them on the second pass - not enough information. I'd rather handle them on the first pass when we can easily do that and then do exact equivalent of the second pass (top to bottom) of your approach. Endianness type checks can be easily combined with the first pass, but not with the second... - 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
