[issue16277] Objects/longobject.c not compiled without long long

Serhiy Storchaka added the comment: I close this issue as the main bug was fixed. For incidental bug I open issue16280. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.2, Python 3.3 ___ Python tracker

[issue16277] Objects/longobject.c not compiled without long long

Mark Dickinson added the comment: Let's keep it simple and just drop the special case for 3.4. -- ___ Python tracker ___ ___ Python-bu

[issue16277] Objects/longobject.c not compiled without long long

Serhiy Storchaka added the comment: > So maybe the fix should be to special case zero in PyLong_AsVoidPtr, and > turn 0L back into NULL there? Yes, of course. If we have a special case in PyLong_FromVoidPtr(), it is wrong that we do not have the special case in PyLong_AsVoidPtr(). But this will

[issue16277] Objects/longobject.c not compiled without long long

Mark Dickinson added the comment: I've fixed the missing branch in 3.2, 3.3 and 3.4. -- assignee: -> mark.dickinson versions: -Python 3.2, Python 3.3 ___ Python tracker ___ ___

[issue16277] Objects/longobject.c not compiled without long long

Roundup Robot added the comment: New changeset bedb2903d71e by Mark Dickinson in branch '3.2': Issue #16277: in PyLong_FromVoidPtr, add missing branch for sizeof(void*) <= sizeof(long). http://hg.python.org/cpython/rev/bedb2903d71e New changeset 8ce04be1321c by Mark Dickinson in branch '3.3': I

[issue16277] Objects/longobject.c not compiled without long long

Mark Dickinson added the comment: > Undefined behavior (or may be just the wrong behavior), we obtain later, > > when > converting in PyLong_AsVoidPtr() zero integer back to pointer. On > platforms > where converting NULL to an integer doesn't give zero it's a bug. So maybe the fix should be

[issue16277] Objects/longobject.c not compiled without long long

Serhiy Storchaka added the comment: > Okay, but do you agree that (1) there's no undefined behaviour, and (2) > removing this code has the potential to change results on platforms where > converting NULL to an integer doesn't give zero? Undefined behavior (or may be just the wrong behavior), we

[issue16277] Objects/longobject.c not compiled without long long

Mark Dickinson added the comment: > "0" lexeme is not 0 integer. Ah yes, true. C99 6.3.2.3 specifies an "integer *constant* expression". So I was mistaken in thinking that converting an arbitrary integer-valued expression with value 0 to (void*) must always give a NULL pointer. > I think it

[issue16277] Objects/longobject.c not compiled without long long

Serhiy Storchaka added the comment: > This doesn't seem very likely, since then the C implementation wouldn't > roundtrip when converting that other pointer to an integer and back to a > pointer. (C99 6.3.2.3 says that (void *)0 is a null pointer constant.) "0" lexeme is not 0 integer. In expre

[issue16277] Objects/longobject.c not compiled without long long

Mark Dickinson added the comment: > If on some platform (uintptr_t)NULL != 0, then some other address can be > reflected to 0. This doesn't seem very likely, since then the C implementation wouldn't roundtrip when converting that other pointer to an integer and back to a pointer. (C99 6.3.2.

[issue16277] Objects/longobject.c not compiled without long long

Serhiy Storchaka added the comment: > For the second part, I don't see any undefined behaviour here. Can you > explain where the undefined behaviour comes from? And are you sure that > this is really just an optimization? It looks as though it might be > deliberately there to make sure that th

[issue16277] Objects/longobject.c not compiled without long long

Mark Dickinson added the comment: Actually, I think that special case needs to be added to the first branch as well. -- ___ Python tracker ___ __

[issue16277] Objects/longobject.c not compiled without long long

Mark Dickinson added the comment: First part of the patch looks fine to me. For the second part, I don't see any undefined behaviour here. Can you explain where the undefined behaviour comes from? And are you sure that this is really just an optimization? It looks as though it might be deli

[issue16277] Objects/longobject.c not compiled without long long

New submission from Serhiy Storchaka: Preprocessor directives emit error in PyLong_FromVoidPtr: PyLong_FromVoidPtr: sizeof(void*) > sizeof(long), but no long long if HAVE_LONG_LONG not defined. Here is a patch which adds missing branch (lost somewhere in 2->3 translation). Also removed non-n