Boost C++ Libraries: Ticket #3911: Boost.Serialization test failures on AIX with vacpp

attachment set

ccambly@… — Mon, 08 Feb 2010 20:37:11 GMT

attachment → cstdint.hpp.patch

owner changed

Robert Ramey — Thu, 11 Feb 2010 17:24:34 GMT

owner changed from Robert Ramey to John Maddock

I THINK this is the correct person to deal with this. If I'm wrong about this, feel free to bounce it back to me.

Robert Ramey

owner changed

anonymous — Thu, 11 Feb 2010 18:44:58 GMT

owner changed from John Maddock to Robert Ramey

Whatever the cause is, I'm not convinced that this is the correct fix.

I note that with the regression tests (32-bit) run with vacpp 10.1 that the integer tests are all compiling.

Are you really saying that there is no int64_t in stdint.h? Come to that I don't see how this macro can be defined in 64-bit mode either?

I believe the problem here is in polymorphic_iarchive.hpp, rather than:

    #if !defined(BOOST_NO_INTRINSIC_INT64_T)
    virtual void load(boost::int64_t & t) = 0;
    virtual void load(boost::uint64_t & t) = 0;
    #endif

It should be:

    #if defined(BOOST_HAS_LONG_LONG)
    virtual void load(boost::long_long_type & t) = 0;
    virtual void load(boost::ulong_long_type & t) = 0;
    #elif defined(BOOST_HAS_MS_INT64)
    virtual void load(__int64 & t) = 0;
    virtual void load(unsigned __int64 & t) = 0;
    #endif

In other word if you overload on type, then overload by "long long" or equivalent as well. Alternatively overload by size: int16_t, int32_t etc (but this may miss some types out if they're the same size as each other, causing problems down the road). But whatever you do don't mix the two!

BTW long long will be part of the next standard, so we should be supporting this as a native type where available anyway.

HTH, John.

ccambly@… — Thu, 11 Feb 2010 23:25:54 GMT

I will retract my patch.

The problem for vacpp is that those function overloads in polymorphic_iarchive.hpp are controlled by the macro BOOST_NO_INTRINSIC_INT64_T, but inside of the tests them selves the macro used is BOOST_NO_INT64_T. It is possible to have one macro defined and not the other.

I originally was changing the tests A.ipp A.cpp A.hpp to use

#if !(defined(BOOST_NO_INT64_T)

defined(BOOST_NO_INTRINSIC_INT64_T))

instead of #ifndef BOOST_NO_INT64_T which worked as well.

I changed my mind about the fix upon seeing code for _hpux in cstdint.h doing something to control the macro BOOST_NO_INT64_T but I'm really not sure what is the real issue.

Johns change sounds reasonable.

ccambly@… — Fri, 12 Feb 2010 17:59:38 GMT

The section of code at the top of polymorphic_oarchive.hpp

determine if its necessary to handle (u)int64_t specifically i.e. that its not a synonym for (unsigned) long if there is no 64 bit int or if its the same as a long we shouldn't define separate functions for int64 data types. #if defined(BOOST_NO_INT64_T)

#define BOOST_NO_INTRINSIC_INT64_T

#else

#if defined(ULLONG_MAX)

#if(ULONG_MAX == 18446744073709551615ul) 264 - 1

#define BOOST_NO_INTRINSIC_INT64_T vacpp gets here

#endif

...

So we have BOOST_NO_INT64_T not defined and BOOST_NO_INTRINSIC_INT64_T defined. In A.hpp we will get the members for f, and g defined.

#ifndef BOOST_NO_INT64_T boost::int64_t f; boost::uint64_t g; #endif

but in polymorphic_oarchive.hpp we do not get the declarations for

#if !defined(BOOST_NO_INTRINSIC_INT64_T) virtual void save(const boost::int64_t t) = 0; virtual void save(const boost::uint64_t t) = 0; #endif

status changed; resolution set

Robert Ramey — Fri, 26 Feb 2010 06:44:48 GMT

status new → closed
resolution → fixed

1) I've implemented John's suggestion. should show up in the trunk in a while.

2) seems like the analogous fix should be made in polymorphic_oarchive.hpp . correct?

Robert Ramey

Robert Ramey — Fri, 26 Feb 2010 06:49:39 GMT

looks the following headers should also get similar treatment

collection_traits.hpp polymorphic_oarchive_route.hpp