[boost] Re: [Python-Dev] long long configuration

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-12 05:01:18

From: "Tim Peters" <tim.one_at_[hidden]>

> [David Abrahams]
> > I recently came across a nasty configuration conflict between boost and
> > python.
> >
> > In LongObject.h we have:
> >
> >     #ifdef HAVE_LONG_LONG
> >
> >     /* Hopefully this is portable... */
> >     #ifndef ULONG_MAX
> >     #define ULONG_MAX 4294967295U
> >     #endif
> >     #ifndef LONGLONG_MAX
> >     #define LONGLONG_MAX 9223372036854775807LL
> >     #endif
> >     #ifndef ULONGLONG_MAX
> >     #define ULONGLONG_MAX 0xffffffffffffffffULL
> >     #endif
> >
> > Well, it turns out that boost detects whether the compiler supports
long
> > long by #including <limits.h> and looking for these macros:
> >
> > #include <limits.h>
> > # if !defined(BOOST_MSVC) && !defined(__BORLANDC__) \
> >    && (defined(ULLONG_MAX) || defined(ULONG_LONG_MAX) ||
> > defined(ULONGLONG_MAX))
> > #  define BOOST_HAS_LONG_LONG
> > #endif
> >
> > So it turns out that on some platforms, Python's configuration sets
> > HAVE_LONG_LONG even when limits.h doesn't include definitions of these
> > macros.
>
> Yes.  Python cares about the conceptual type, not about how a platform
> spells it.
>
> > For example, there's MSVC6, where Python substitutes __int64 for
> > long long using its LONG_LONG macro. However, I didn't actually notice
> > the problem
>
> What problem?

Uh, sorry. Depending on the order of #includes, Python's headers can
confuse Boost's configuration.

> > until I tried linking something at LLNL where they're using an older
KCC.
> > Two translation units had different ideas of BOOST_HAS_LONG_LONG,
>
> Why was that?  Nothing you showed us for it, unless there's an implied
> #include of Python.h before the Boost limits.h block you did show us.

Because one translation unit said (in effect):

#include <Python.h>          // defines ULONGLONG_MAX
#include <boost/config.hpp>  // decides long long is available

and the other said:

#include <boost/config.hpp> // decides long long is unavailable
#include <Python.h>         // defines ULONGLONG_MAX (harmless this time)

> > so linking failed when one of them was looking for the long long
support
> > supposedly provided by another. I'm surprised it wasn't a worse problem
> > with MSVC6, because after all, it doesn't even supply a type called
> > "long long".
> >
> > Is there any chance that something can be done to prevent this sort of
> > conflict?
>
> Rather than try to extract a clear question out of this <wink>,

Too late (I hope!)

> let me turn
> it around:  would your problem go away if this code in LongObject.h went
> away entirely?  Python has no business defining ULONG_MAX anymore (that's
> left over from K&R C days), and I'm sure I got rid of all uses of
> LONGLONG_MAX and ULONGLONG_MAX in 2.2 (I vaguely recall some; they
weren't
> really needed, and won't be needed again).

Actually, that was the answer I was hoping you'd come up with. I'd also
suggest prefixing HAVE_LONG_LONG with some kind of PYTHON_ grist to keep it
out of the way of more-naive applications, but I don't want to push my luck
\<wink> -- I still remember what happened when I suggested that _Py_...
names should be avoided!

-Dave