[rfc] __builtin_offsetof for c and c++

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

| On Fri, Jan 02, 2004 at 05:46:32AM +0100, Gabriel Dos Reis wrote:
| >    (1) Did you test what would happen in templates?  i.e.,
| > 
| >        template<class T>
| >          struct X {
| >             int foo_offset() { return offsetof(T, foo); }
| >          };  
| > 
| >        struct A {
| >           int foo;
| >        };
| > 
| >        int main() { return X<A>().foo_offset(); }
| 
| ICE.  Clearly I'm not deferring things as I ought for templates.
| I sorta thought that would happen automatically, what with calling
| back into the parser like I am...

I think things may work as follows:
    (1) if after parsing, neither the type nor the member designator is
        dependent, then you may safely proceed the semantics analysis
        and compute the value; otherwise
    (2) you build an OFFSETOF_EXPR (a new node introduced via
        cp/cp-tree.def) that you instantiate later in tsubst_expr and
        tsubst_copy, tsubst_copy_and_build.  

| > I would just name the whole think __offsetof__, i.e. with no __builtin
| > prefix.
| 
| This is not in line with __builtin_va_arg, etc.

OK, that makes sense.  I was just repeating feelings other people may
have 

    http://gcc.gnu.org/2003-03/msg00702.html

| > I think you first need to check whether type is a POD class-type
| > before calling build_unraryop.
| 
| For a pedwarn, perhaps, but as noted elsewhere, all other polled
| compilers handle the "obvious" non-POD cases as well.

a pedwarn is fine for the moment.  I think your approach makes it
easier later to add the extensions to other non-POD cases once, the
C++ committee decides what to do.

Thanks,

-- Gaby