Mark Dickinson dicki...@gmail.com added the comment:
It seems likely that this is a wine bug rather than a Python bug.
--
resolution: - works for me
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4880
New submission from Luke Kenneth Casson Leighton l...@lkcl.net:
there's probably a better way to do this (or a better reason), but
LONG_MIN and LONG_MAX end up as the wrong constant types when compiling
python2.5.2 under wine (don't ask...)
PyObject *
PyInt_FromSsize_t(Py_ssize_t ival)
{
if
Mark Dickinson dicki...@gmail.com added the comment:
Interesting. How many of those casts are actually necessary to make
things work? Have you figured out more precisely why this is failing?
E.g., is it somehow that LONG_MIN ends up being an unsigned constant?
It seems to me that a better
Luke Kenneth Casson Leighton l...@lkcl.net added the comment:
oh, duh - 2L not 1L yes you're right :)
yeh i believe it's likely to be because in PC/pyconfig.h LONG_MAX is
#defined to 7fff not 7fffL i'll double-check.
you're right that would make life a looot easier.
Luke Kenneth Casson Leighton l...@lkcl.net added the comment:
hmmm... noo, it's already #defined to 0x7fffL in
both PC/pyconfig.h _and_ in /usr/include/wine/msvcrt/limits.h
so this works (Include/pyports.h)
#ifdef __WINE__ /* weird: you have to typecast 0x7fffL to long */
Martin v. Löwis mar...@v.loewis.de added the comment:
I think you should study the preprocessor output to find out what
LONG_MAX really expands to, at the point where it is used.
In any case, I'm tempted to close this as works for me - 0x7FFFL
is definitely a long constant in all compilers
