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