This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
Type: Stage:
Components: Versions: Python 2.5
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: lkcl, loewis, mark.dickinson
Priority: normal Keywords:

Created on 2009-01-08 14:56 by lkcl, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (6)
msg79411 - (view) Author: Luke Kenneth Casson Leighton (lkcl) Date: 2009-01-08 14:56
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 ((long)ival >= (long)LONG_MIN && (long)ival <= (long)LONG_MAX)
    {
        return PyInt_FromLong((long)ival);
    }
    return _PyLong_FromSsize_t(ival);
}
msg79418 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-01-08 15:46
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 fix would be to fix LONG_MIN and LONG_MAX 
somewhere in the configuration files;  there are bound to be more uses of 
LONG_MIN and LONG_MAX in the source that are going to cause problems.

P.S.  Looking at your python-dev messages, does len([1, 2]) really return 
1L?  Not 2L?
msg79422 - (view) Author: Luke Kenneth Casson Leighton (lkcl) Date: 2009-01-08 16:40
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 7fffffff not 7fffffffL i'll double-check.

you're right that would make life a looot easier.
msg79424 - (view) Author: Luke Kenneth Casson Leighton (lkcl) Date: 2009-01-08 16:47
.... hmmm... noo, it's already #defined to 0x7fffffffL 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 0x7fffffffL to long */
#undef LONG_MAX
#undef LONG_MIN
#define LONG_MAX ((long)0x7FFFFFFFL)
#define LONG_MIN ((long)(-LONG_MAX-1))
#else
#ifndef LONG_MAX
#if SIZEOF_LONG == 4
#define LONG_MAX 0X7FFFFFFFL
#elif SIZEOF_LONG == 8
#define LONG_MAX 0X7FFFFFFFFFFFFFFFL
#else
#error "could not set LONG_MAX in pyport.h"
#endif
#endif

#ifndef LONG_MIN
#define LONG_MIN (-LONG_MAX-1)
#endif

#endif /* __WINE__ */
msg79436 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-01-08 20:42
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" - 0x7FFFFFFFL
is definitely a long constant in all compilers I know of.
msg81642 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-02-11 13:47
It seems likely that this is a wine bug rather than a Python bug.
History
Date User Action Args
2022-04-11 14:56:43adminsetgithub: 49130
2009-02-11 13:47:54mark.dickinsonsetstatus: open -> closed
resolution: works for me
messages: + msg81642
2009-01-08 20:42:03loewissetnosy: + loewis
messages: + msg79436
2009-01-08 16:47:55lkclsetmessages: + msg79424
2009-01-08 16:40:56lkclsetmessages: + msg79422
2009-01-08 15:46:22mark.dickinsonsetnosy: + mark.dickinson
messages: + msg79418
2009-01-08 14:56:28lkclcreate