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

From: Tim Peters (tim.one_at_[hidden])
Date: 2002-07-12 11:10:30

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

Note that I already removed all this from current CVS (except for the #ifdef
HAVE_LONG_LONG, which is still needed for code following the quoted block).

That's for 2.3.  Would it be of value to remove it from 2.2.2 too?

>> What problem?

> Uh, sorry. Depending on the order of #includes, Python's headers can
> confuse Boost's configuration.
> ...
> 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)

OK, that's what I figured -- blatant user error, and probably a deliberate
and malicious one too <wink>.

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

IIRC, we said we wouldn't avoid them, and I agree that if you were to
suggest it, you'd likely get the same kind of response to suggesting we slap
PYTHON_ in front of HAVE_XYZ names.  A problem is that those more-naive
applications are at least equally likely to *rely* on Python.h continuing to
expose the same set of names it currently exposes, advertised or not.
Indeed, I'm afraid there's a real chance I broke someone's extension by
removing the unadvertised LONGLONG_MAX name.  In any case, it's too much
fiddling just to save you the effort of ordering a pair of includes
consistently <0.9 wink>.