[issue15144] Possible integer overflow in operations with addresses and sizes.

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15144] Possible integer overflow in operations with addresses and sizes.

Mark Dickinson added the comment: > Mark, please open a new discussion. Done: issue 15992. -- ___ Python tracker ___ ___ Python-bugs

[issue15144] Possible integer overflow in operations with addresses and sizes.

Antoine Pitrou added the comment: Committed in 3.3(.1). -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.3 -Python 3.4 ___ Python tracker ___

[issue15144] Possible integer overflow in operations with addresses and sizes.

Roundup Robot added the comment: New changeset 99112b851b25 by Antoine Pitrou in branch 'default': Issue #15144: Fix possible integer overflow when handling pointers as integer values, by using Py_uintptr_t instead of size_t. http://hg.python.org/cpython/rev/99112b851b25 -- nosy: +pytho

[issue15144] Possible integer overflow in operations with addresses and sizes.

Antoine Pitrou added the comment: Thanks for the patch! These macros will be useful. -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue15144] Possible integer overflow in operations with addresses and sizes.

Serhiy Storchaka added the comment: Mark, please open a new discussion, so we don't lose it and that was the place for discussion. -- ___ Python tracker ___

[issue15144] Possible integer overflow in operations with addresses and sizes.

Mark Dickinson added the comment: Apologies; I got distracted from the main point of this issue with the strict aliasing stuff, and then it fell off the to-do list. Unassigning; Antoine or Victor, do you want to take this? -- assignee: mark.dickinson ->

[issue15144] Possible integer overflow in operations with addresses and sizes.

Serhiy Storchaka added the comment: Well, here is a new patch. The five new macros moved to pymacros.h and used in more files. -- Added file: http://bugs.python.org/file27232/align_operations2.patch ___ Python tracker

[issue15144] Possible integer overflow in operations with addresses and sizes.

STINNER Victor added the comment: > Perhaps the three new macros should be made available in a .h file? Good idea. Maybe pymacros.h? These macros need to be documented (with a comment in the .h file) -- nosy: +haypo ___ Python tracker

[issue15144] Possible integer overflow in operations with addresses and sizes.

Serhiy Storchaka added the comment: > Perhaps the three new macros should be made available in a .h file? > (in which case they should be private, i.e. start with _). Perhaps. There are similar macros in other files (Include/objimpl.h, Objects/obmalloc.c, Python/pyarena.c, Modules/expat/xmlpars

[issue15144] Possible integer overflow in operations with addresses and sizes.

Antoine Pitrou added the comment: Perhaps the three new macros should be made available in a .h file? (in which case they should be private, i.e. start with _). -- type: security -> behavior versions: +Python 3.4 -Python 3.3 ___ Python tracker

[issue15144] Possible integer overflow in operations with addresses and sizes.

Serhiy Storchaka added the comment: Please, Mark or some other C expert, can you do a code review for the patch? -- ___ Python tracker ___ ___

[issue15144] Possible integer overflow in operations with addresses and sizes.

Changes by Serhiy Storchaka : -- keywords: +needs review priority: normal -> low ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue15144] Possible integer overflow in operations with addresses and sizes.

Serhiy Storchaka added the comment: > Ah; were the strict aliasing problems already there before the patch? I >didn't check. Please open separate issue for this. -- stage: -> patch review ___ Python tracker __

[issue15144] Possible integer overflow in operations with addresses and sizes.

Mark Dickinson added the comment: > I don't see what the undefined behavior. Can you specify exactly the > item of the Standard, in which it is mentioned? It's C99 section 6.5, paragraph 7: "An object shall have its stored value accessed only by an lvalue expression that has one of the follow

[issue15144] Possible integer overflow in operations with addresses and sizes.

Serhiy Storchaka added the comment: > If we're worrying about undefined behaviour, it looks like recent > optimizations have *introduced* new undefined behaviour in the form of strict > aliasing violations. E.g., from ascii_decode: > > unsigned long value = *(const unsigned long *) _p; >

[issue15144] Possible integer overflow in operations with addresses and sizes.

Mark Dickinson added the comment: I'll see if I can come up with a patch, and open a new issue for it (since I've successfully derailed this issue from its original topic) -- ___ Python tracker __

[issue15144] Possible integer overflow in operations with addresses and sizes.

Mark Dickinson added the comment: > How would it work? We would have to add various unions to the > PyUnicode_Object definition? No, you'd just need a temporary union defined in unicodeobject.c that would look something like: typedef union { unsigned long v; char s[SIZEOF_LONG]; } U; (with b

[issue15144] Possible integer overflow in operations with addresses and sizes.

Antoine Pitrou added the comment: > N.B. This could probably be fixed without affecting performance by > using the usual union trick. How would it work? We would have to add various unions to the PyUnicode_Object definition? -- ___ Python tracker <

[issue15144] Possible integer overflow in operations with addresses and sizes.

Mark Dickinson added the comment: N.B. This could probably be fixed without affecting performance by using the usual union trick. (IIUC, that trick was technically still undefined behaviour for a while, but was eventually made legal by C99 + TC3.) As far as I know there aren't any instances

[issue15144] Possible integer overflow in operations with addresses and sizes.

Mark Dickinson added the comment: > (also, I'm not sure what optimization it could actually make) Me neither, but it doesn't seem safe to assume that no compiler will take advantage of this. I don't want to start guessing what compilers might or might not do; it would be much better simply

[issue15144] Possible integer overflow in operations with addresses and sizes.

Antoine Pitrou added the comment: > This should really be fixed; compilers are known to make optimizations > based on the assumption that this sort of undefined behaviour doesn't > occur. Doesn't the compiler have all the necessary information here? It's not like a subroutine is called. (als

[issue15144] Possible integer overflow in operations with addresses and sizes.

Mark Dickinson added the comment: If we're worrying about undefined behaviour, it looks like recent optimizations have *introduced* new undefined behaviour in the form of strict aliasing violations. E.g., from ascii_decode: unsigned long value = *(const unsigned long *) _p; (here _p has

[issue15144] Possible integer overflow in operations with addresses and sizes.

Changes by Mark Dickinson : -- assignee: -> mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue15144] Possible integer overflow in operations with addresses and sizes.

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue15144] Possible integer overflow in operations with addresses and sizes.

New submission from Serhiy Storchaka : In unicodeobject.c and stringlib aligned addresses and sizes are used for optimization. pointer->integer and implicit integer->integer conversions may overflow or underflow on platforms with sizeof(size_t) != sizeof(void *) or sizeof(size_t) != sizeof(int