[C++-sig] Re: Boost.Python and GCC 3.4.2

[Patrick Hartling]

On Wed, 29 Sep 2004 13:05:57 -0400, David Abrahams
<dave at boost-consulting.com> wrote:
> Patrick Hartling <patrick.hartling at gmail.com> writes:
> 
> > The code that GCC is complaining about is the type cast in the last
> > term of the last statement in the following:
> >
> > template <class Data>
> > struct additional_instance_size
> > {
> >     typedef instance<Data> instance_data;
> >     typedef instance<char> instance_char;
> >     static const std::size_t value = sizeof(instance_data) -
> > ((size_t)(&((instance_char *)0)->storage));
> >
> >
> > };
> >
> > I haven't run into this problem before, and I am not sure how to go
> > about fixing it (and submitting a patch if appropriate).  I did find a
> > semi-related discussion on another mailing list with a reference to
> > the relevant part of the C++ Standard:
> >
> >    http://www.cygwin.com/ml/ecos-discuss/2003-02/msg00214.html
> >
> > I have seen reports from other people on this list saying that they
> > are using GCC 3.4 to compile Boost.Python without problems, so I may
> > be doing something wrong.  I have attached some simple test code that
> > reproduces the compiler error.  Is there a way to work around this, or
> > is it a GCC bug?
> 
> It is a GCC bug, but not where you think.  This expression:
> 
>    (&((instance_char *)0)->storage)
> 
> is generated by GCC's C library sizeof() macro.

Do you mean offsetof() here?  I should have looked at the expansion of
BOOST_PYTHON_OFFSETOF before going straight to the full output from
the preprocessor.

> sizeof is required to
> return an integral constant, by whatever means.  So the GCC people
> need to stick in some special compiler magic to make it happy.

After digging into this some more, I think that this is a FreeBSD bug.
 GCC 3.4.2 works just fine on Fedora Core 2 (though I haven't tried
other Linux distributions).  On FreeBSD, stddef.h expands offsetof()
to __offsetof() (from sys/cdefs.h).  __offsetof() is what generates
the above code that GCC 3.4.2 does not like.  I'll let the FreeBSD
folks know about this in hopes of seeing it fixed before FreeBSD 5.3
gets released.

Thanks for pointing me in the right direction on this.

 -Patrick


-- 
Patrick L. Hartling
Research Assistant, VRAC
http://www.137.org/patrick/