On Sun, Jun 24, 2007 at 09:40:06PM +0200, Segher Boessenkool wrote: > >>Why? I'd say it's not better than BUILD_BUG_ON_ZERO() use > >>instead of that ?: > > > >Oh, _that_ part I have no problem with. It's more that it seems that > >the > >gcc optimization is ok at least as an extension. > > Sure, but it's not an extension (yet), but an implementation > side-effect; it would have to be (semi-formally) defined in > the manual to be an extension. Until that happens, anyone > using this "feature" risks haven his code broken at any time > (or, rather, his code already was broken but he didn't know > it). > > See gcc.gnu.org/PR456 for more discussion. Yes it's an old > bug... Humm... Right, so __builtin_offsetof() needs special treatment too. Oh, bugger. Is offsetof(struct foo, a.x[n]) a documented extension? I _know_ that it's not promised by 7.17, but gcc eats it (and obviously that sucker requires extra treatment in that case). Parsing __builtin_offsetof() arguments is going to be fun ;-/ Right now sparse has it as a predefined macro, but if we want to do that kind of analysis, we need to really parse it. OTOH, that's not such a big deal... Parser would need to accept ident ( \[ expr \] | . ident )* there, typecheck would walk down, check types and find offsets of struct members on the way down and build expression on the way back (e.g. in form of constant + sum of stuff from [...]), doing evaluate_expression() on each index and slapping Int_const_expr on created nodes accordingly. In the end, slap the Int_const_expr on resulting expression in obvious way. expand would work as usual, no interesting nodes surviving by that point... OK, that's doable and probably should be split into implementation of __builtin_offsetof() (sans Int_const_expr logics) and Int_const_expr parts merged into the patch that does all handling of integer constant expressions. Joy. OK, folks, disregard 16/16 in the current form; everything prior to it stands on its own. - 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
