Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed #49130

Closed
lkcl mannequin opened this issue Jan 8, 2009 · 6 comments
Closed

PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed #49130

lkcl mannequin opened this issue Jan 8, 2009 · 6 comments

Comments

@lkcl
Copy link
Mannequin

lkcl mannequin commented Jan 8, 2009

BPO 4880
Nosy @loewis, @mdickinson

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2009-02-11.13:47:54.105>
created_at = <Date 2009-01-08.14:56:28.872>
labels = []
title = 'PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed'
updated_at = <Date 2009-02-11.13:47:54.104>
user = 'https://bugs.python.org/lkcl'

bugs.python.org fields:

activity = <Date 2009-02-11.13:47:54.104>
actor = 'mark.dickinson'
assignee = 'none'
closed = True
closed_date = <Date 2009-02-11.13:47:54.105>
closer = 'mark.dickinson'
components = []
creation = <Date 2009-01-08.14:56:28.872>
creator = 'lkcl'
dependencies = []
files = []
hgrepos = []
issue_num = 4880
keywords = []
message_count = 6.0
messages = ['79411', '79418', '79422', '79424', '79436', '81642']
nosy_count = 3.0
nosy_names = ['loewis', 'lkcl', 'mark.dickinson']
pr_nums = []
priority = 'normal'
resolution = 'works for me'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue4880'
versions = ['Python 2.5']

@lkcl
Copy link
Mannequin Author

lkcl mannequin commented Jan 8, 2009

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);
}

@mdickinson
Copy link
Member

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?

@lkcl
Copy link
Mannequin Author

lkcl mannequin commented Jan 8, 2009

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.

@lkcl
Copy link
Mannequin Author

lkcl mannequin commented Jan 8, 2009

.... 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__ */

@loewis
Copy link
Mannequin

loewis mannequin commented Jan 8, 2009

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.

@mdickinson
Copy link
Member

It seems likely that this is a wine bug rather than a Python bug.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant