Ismail Donmez added the comment:
To Neal,
Can you try with -Wstrict-overflow=3 , but yes I am using gcc 4.3 trunk.
To Guido,
I'll check _csv.c issue closely. Shall I create the new bug reports or
will reviewers will do so and CC me maybe?
__
Tracker [EMAIL
Neal Norwitz added the comment:
On Jan 27, 2008 6:45 PM, Ismail Donmez [EMAIL PROTECTED] wrote:
Can you try with -Wstrict-overflow=3 , but yes I am using gcc 4.3 trunk.
I just tried with =1, =2, =3, and no =. All the same result: no warning.
Ismail, thanks for going through all this
Guido van Rossum added the comment:
Don't create new bug reports!
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Python-bugs-list mailing list
Unsubscribe:
Ismail Donmez added the comment:
_sre.c case is the most interesting one , compiler says :
./Modules/_sre.c:1002: warning: assuming signed overflow does not occur
when simplifying conditional to constant
./Modules/_sre.c:1069: warning: assuming signed overflow does not occur
when simplifying
Ismail Donmez added the comment:
For xmlparse.c compiler says :
Modules/expat/xmlparse.c:5337: warning: assuming signed overflow does
not occur when simplifying conditional to constant
Its impossible for j to overflow here due to name[i] check but I am not
sure what gcc is optimizing here.
Guido van Rossum added the comment:
for (i = 0; i strlen(field) ; i++) {
This looks inefficient. Why not
for (i = 0; field[i] != '\0'; i++) {
???
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
Ismail Donmez added the comment:
Hah strlen in a loop, a nice beginner mistake but its 5.30 AM here so
please excuse me, Guido your version of course is way better. But with
that version compiler issues
Modules/_csv.c:969: warning: assuming signed overflow does not occur when
simplifying
Changes by Neal Norwitz:
--
nosy: +nnorwitz
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Python-bugs-list mailing list
Unsubscribe:
Ismail Donmez added the comment:
Final patch should be complete. Used a trick in _sre.c, instead of i 0
, I used
i + i i to trick gcc.
Added file: http://bugs.python.org/file9242/fix-overflows-final.patch
__
Tracker [EMAIL PROTECTED]
Christian Heimes added the comment:
Ismail Donmez wrote:
Ismail Donmez added the comment:
Final patch should be complete. Used a trick in _sre.c, instead of i 0
, I used
i + i i to trick gcc.
I'm going to review your patch later.
Christian
__
Tracker
Christian Heimes added the comment:
Ismail Donmez wrote:
Final patch should be complete. Used a trick in _sre.c, instead of i 0
, I used
i + i i to trick gcc.
Added file: http://bugs.python.org/file9242/fix-overflows-final.patch
Does the C89 standard allow this code?
int q = 1;
int p
Martin v. Löwis added the comment:
Does the C89 standard allow this code?
int q = 1;
int p = (unsigned)q;
I've never seen an unsigned cast without a type.
Yes, that's fine; it's a different spelling of unsigned int.
In C99, 6.7.2p1 defines the following groups as equivalent:
- short,
Ismail Donmez added the comment:
Hi Christian,
unsigned cast is actually suggested by GCC developers to force correct
wrapping for signed types. And thanks to Martin, it makes sense :-)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
Christian Heimes added the comment:
Crashes ain't good ;)
I suggest that you chance only a small portion of files at a time, then
make ./python Lib/test/regrtest.py. Start with the Parser, then move
over to AST and the rest of Python/.
You may have to remove all pyc and pyo files if you
Changes by Christian Heimes:
--
priority: - high
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Python-bugs-list mailing list
Unsubscribe:
Ismail Donmez added the comment:
I created a git repo for my fixes over
http://repo.or.cz/w/pytest.git?a=shortlog;h=overflow-fix .
Now as tiran suggested I fix one file and make sure nothing regressed.
But! Feel free to beat me to it and fix this. I am all new to this and
progress might be and
Ismail Donmez added the comment:
With second patch now python builds without any overflow warnings, no
new regressions. Please test and/or review.
Only thing left is fixing Modules subdirectory.
Thanks.
Added file: http://bugs.python.org/file9238/fix-overflows-try2.patch
Ismail Donmez added the comment:
Possibly last one before final patch, only Modules/_sre.c left to fix, I
appreciate help on that. Please ignore tab problems, I think that can be
fixed later on.
Thanks.
Added file: http://bugs.python.org/file9239/fix-overflows-try3.patch
Ismail Donmez added the comment:
Problem was that -Wall at the end was resetting -Wstrict-overflow, so
here is the current results for signed overflow warnings (python 2.5
branch SVN), a lot of them :
Parser/acceler.c: In function 'fixstate':
Parser/acceler.c:90: warning: assuming signed
Ismail Donmez added the comment:
-Wstrict-overflow=5 is not valid afaik its 1-3, 3 for most verbose also
you need a recent gcc 4.3 snapshot for best results, check your
distribution for gcc-snapshot package.
About the -Wall thing it seems to be a gcc bug, but for now workaround
is easy :-)
Ismail Donmez added the comment:
Replace -fwrapv with -Wstrict-overflow=3 -Werror=strict-overflow when
supported. Guido, does this do what you wanted?
Regards,
ismail
Added file: http://bugs.python.org/file9205/overflow-error.patch
__
Tracker [EMAIL PROTECTED]
Martin v. Löwis added the comment:
Btw I think we need an unsigned version of Py_ssize_t to fix this
problem cleanly. I am not sure if you would agree with me though.
There is an unsigned version, it's called size_t.
__
Tracker [EMAIL PROTECTED]
Changes by Ismail Donmez:
Added file: http://bugs.python.org/file9210/overflow-error4.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Python-bugs-list mailing
Guido van Rossum added the comment:
The proper thing to do here is to add
-Werror=strict-overflow
to the CFLAGS (*before* -Wall -- we should fix the position of -Wall!);
this will turn all those spots into errors, forcing us to fix them, and
alerting users who might be using a newer compiler
Christian Heimes added the comment:
The -fwrapv doesn't look right. You aren't testing for -fwrapv at all ;)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Guido van Rossum added the comment:
Would you mind also adding patches for the places you think you can fix,
and providing us with a list of places you need help with?
O'm hoping that Greg or Christian can help reviewing these and
committing them. Thanks much for your help BTW!
--
Guido van Rossum added the comment:
Close, I'd like to keep the -fwrapv if -Wstrict-overflow isn't supported.
Also, would checking this in mean we can't build with GCC 4.3 until
those issues are all fixed?
__
Tracker [EMAIL PROTECTED]
Ismail Donmez added the comment:
No I mean we need a new unsigned variant. Else we will have to cast it
to unsigned for many overflow cases which is ugly.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
Ismail Donmez added the comment:
Btw I think we need an unsigned version of Py_ssize_t to fix this
problem cleanly. I am not sure if you would agree with me though.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
Christian Heimes added the comment:
I don't think we can make Py_ssize_t unsigned. On several occasions
Python uses -1 as error flag or default flag.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
Guido van Rossum added the comment:
An unsigned variant of Py_ssize_t would just be size_t -- that's a much
older type than ssize_t. I don't think we need to invent a Py_ name for it.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
Ismail Donmez added the comment:
Yes it breaks compilation with gcc 4.3. Fixing these bugs are mostly
s/int/unsigned int. But some parts of code need Python wisdom :/
New patch attached adressing your comment.
Added file: http://bugs.python.org/file9207/overflow-error2.patch
Changes by Ismail Donmez:
Added file: http://bugs.python.org/file9209/overflow-error3.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Python-bugs-list mailing
Guido van Rossum added the comment:
I think the -Wstrict-overflow option may not be enough for the audit we
need.
The overflow issue in expandtabs() still exists (in 2.5 as well as in
the trunk):
if (*p == '\n' || *p == '\r') {
i += j;
old_j = j = 0;
Ismail Donmez added the comment:
FWIW I reported this to GCC bugzilla as a missing diagnostic @
http://gcc.gnu.org/PR34843
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
Martin v. Löwis added the comment:
FWIW gcc hacker Ian Lance Taylor has a nice article about signed
overflow optimizations in gcc, see http://www.airs.com/blog/archives/120
. Reading that it might be better to use -fno-strict-overflow instead of
-fwrapv.
Please be specific. I read it, and I
Ismail Donmez added the comment:
Ian says -fno-strict-overflow still allows some optimizations, and his
example code shows less assembly is produced with -fno-strict-overflow.
But of course your opinion matters on this one, not mine.
Regards,
ismail
__
Tracker
Alexandre Vassalotti added the comment:
Hm. I don't get any warning, related to the overflow issue, neither with
-Wstrict-overflow=3, nor -Wstrict-overflow=5. Are the cPickle warnings
already fixed?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
Ismail Donmez added the comment:
Make sure you use gcc 4.3 trunk and at least -O2 is enabled. I tested
revision 59895 from release25-maint branch.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
Ismail Donmez added the comment:
FWIW gcc hacker Ian Lance Taylor has a nice article about signed
overflow optimizations in gcc, see http://www.airs.com/blog/archives/120
. Reading that it might be better to use -fno-strict-overflow instead of
-fwrapv.
Regards,
ismail
Guido van Rossum added the comment:
Alexandre, which Python version did you compile with -Wstrict-overflow?
It would behoove us to check 2.5.2 thoroughly before it goes out the door.
I will contact Coverity to ask if they check for this kind of thing.
(They just upgraded us to Rung 2,
Guido van Rossum added the comment:
Marc-Andre: what do you mean by breaking lots and lots of extensions?
Extensions also contain buffer overflow checks (at least I hope they do
:-) and those should also be guaranteed safe by using -fwrapv or
-fno-strict-overflow (GCC 4.2 and higher) until
Ismail Donmez added the comment:
-Wstrict-overflow=3 with gcc 4.3 trunk here shows :
Modules/cPickle.c: In function 'Unpickler_noload':
Modules/cPickle.c:4232: warning: assuming signed overflow does not occur
when assuming that (X - c) X is always false
Modules/cPickle.c:194: warning:
Martin v. Löwis added the comment:
But also note that -fno-strict-aliasing is also just another workaround
and its more serious than -fwrapv.
Sure - however, that is fixed in Python 3 (and unrelated to this issue)
__
Tracker [EMAIL PROTECTED]
Gregory P. Smith added the comment:
heh if thats the only warning gcc -Wstrict-overflow gives then I've
mistitled the bug. Fixed. It'll take some manual code review.
Anyone know if the commercial analysis tools we've run the code base
through in the past can find these for us?
--
101 - 145 of 145 matches
Mail list logo
