Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15144
___
___
Python-bugs-list mailing list
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 rep...@bugs.python.org
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 -
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 rep...@bugs.python.org
http://bugs.python.org/issue15144
___
Antoine Pitrou added the comment:
Thanks for the patch! These macros will be useful.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15144
___
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:
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 rep...@bugs.python.org
Mark Dickinson added the comment:
Mark, please open a new discussion.
Done: issue 15992.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15144
___
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
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
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,
Serhiy Storchaka added the comment:
Please, Mark or some other C expert, can you do a code review for the patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15144
___
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 rep...@bugs.python.org
Changes by Serhiy Storchaka storch...@gmail.com:
--
keywords: +needs review
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15144
___
Mark Dickinson dicki...@gmail.com 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
Antoine Pitrou pit...@free.fr 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
Mark Dickinson dicki...@gmail.com 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
Mark Dickinson dicki...@gmail.com 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
Antoine Pitrou pit...@free.fr 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?
--
___
Mark Dickinson dicki...@gmail.com 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
Mark Dickinson dicki...@gmail.com 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 rep...@bugs.python.org
Serhiy Storchaka storch...@gmail.com 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
Mark Dickinson dicki...@gmail.com 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
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: - mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15144
___
___
New submission from Serhiy Storchaka storch...@gmail.com:
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
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15144
___
___
26 matches
Mail list logo
