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

From: Tim Peters (tim.one_at_[hidden])
Date: 2002-07-11 23:54:15

[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?

> 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.

> 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>, 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).