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
>>> #ifndef LONGLONG_MAX
>>> #define LONGLONG_MAX 9223372036854775807LL
>>> #ifndef ULONGLONG_MAX
>>> #define ULONGLONG_MAX 0xffffffffffffffffULL
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>.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk