C++ PATCH: Fix PR 13275

Richard Henderson rth@redhat.com
Thu Dec 18 02:32:00 GMT 2003


On Wed, Dec 17, 2003 at 06:01:07PM -0800, Mark Mitchell wrote:
> I know that we presently decompose some things too early, as you say,
> but I'm not sure how that relates to "offsetof".

Because if I let &s.x survive in build_unary_op(ADDR_EXPR), then
"&((type *)0)->x" is not immediately folded to a constant, and that
breaks uses of the offsetof macro that are outside of functions.

> To implement "__builtin_offsetof (type, member)" in C++, the parser
> would basically just have to reconstruct all the stuff that's presently
> in the macro.  For example, you want to do name lookup for member as if
> you had an expression of type "type" on the left-hand side of ".
> member".

Yes.  For the C front end this amounts to prolly 10 lines of code,
since all the hard stuff is done in build_component_ref and 
build_array_ref.

> You might as well just let the preprocessor do the work for you.

Possibly.

Joseph mentioned the possibility of better diagnostics with the
__builtin_offsetof form.

And I think Gaby's point is that it is simply not possible to abuse
__builtin_offsetof, whereas __offsetof__ could be used to cheat
in some instance.  In what way, I'm not sure, but ...


r~



More information about the Gcc-patches mailing list