First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 34843
Product:  
Component:  
Status: RESOLVED
Resolution: DUPLICATE of bug 32102
Assigned To: Not yet assigned to anyone <unassigned@gcc.gnu.org>
Host:
Reported against  
Priority:  
Severity:  
Target Milestone:  
 
 
Target:
Reporter: Ismail "cartman" Donmez <ismail@namtrac.org>
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
unicodeobject.i Preprocessed source code for unicodeobject.c text/plain 2008-01-18 01:46 71.39 KB Edit
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 34843 depends on: Show dependency tree
Show dependency graph
Bug 34843 blocks:

Additional Comments:






View Bug Activity   |   Format For Printing   |   Clone This Bug


Description:   Last confirmed: 2008-01-18 16:32 Opened: 2008-01-18 01:45
unicodeobject.c from Python 2.5 assumes signed integer overflow in the
following code in unicode_expandtabs function :

i and j are signed integers (defined as ssize_t) :

[...]
        else {
            j++;
            if (*p == '\n' || *p == '\r') {
                i += j;  <=== Possible overflow
                old_j = j = 0;
                if (i < 0) {  <== Code won't work due to undefined overflow
                    PyErr_SetString(PyExc_OverflowError,
                                    "new string is too long");
                    return NULL;
                }
            }
        }
[...]

Now if I compile this file with -O3 -Wstrict-overflow=3 I got no warning
although undefined overflow occurs and code is miscompiled unless -fwrapv is
specified. I think gcc should be warning us here about undefined overflow.

------- Comment #1 From Ismail "cartman" Donmez 2008-01-18 01:46 -------
Created an attachment (id=14964) [edit]
Preprocessed source code for unicodeobject.c

------- Comment #2 From Ian Lance Taylor 2008-01-18 16:32 -------
When I compile this code with current mainline with -O3 -Wstrict-overflow=3 I
get the following warnings:

Objects/unicodeobject.c: In function ‘unicode_startswith’:
Objects/unicodeobject.c:6943: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Objects/unicodeobject.c:6947: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Objects/unicodeobject.c: In function ‘unicode_endswith’:
Objects/unicodeobject.c:6989: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Objects/unicodeobject.c:6992: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Objects/unicodeobject.c: In function ‘unicode_expandtabs’:
Objects/unicodeobject.c:5719: warning: assuming signed overflow does not occur
when simplifying conditional to constant
Objects/unicodeobject.c:5727: warning: assuming signed overflow does not occur
when simplifying conditional to constant
Objects/unicodeobject.c: In function ‘rsplit’:
Objects/unicodeobject.c:368: warning: assuming signed overflow does not occur
when simplifying conditional to constant
Objects/unicodeobject.c: In function ‘PyUnicodeUCS4_Join’:
Objects/unicodeobject.c:4659: warning: assuming signed overflow does not occur
when simplifying conditional to constant
Objects/unicodeobject.c: In function ‘PyUnicodeUCS4_Compare’:
Objects/unicodeobject.c:5376: warning: assuming signed overflow does not occur
when changing X +- C1 cmp C2 to X cmp C1 +- C2
Objects/unicodeobject.c:5376: warning: assuming signed overflow does not occur
when changing X +- C1 cmp C2 to X cmp C1 +- C2

The code you are talking about seems to be around line 5722, so this seems to
provide the warnings that you are looking for.

So: which compiler are you using?  What output do you see?

------- Comment #3 From Ismail "cartman" Donmez 2008-01-18 16:41 -------
Looks like -Wall being at the end disables this warning uh oh. This is invalid,
sorry for taking your time.

------- Comment #4 From Ismail "cartman" Donmez 2008-01-18 17:19 -------
Actually I am reopening this because after talking to Richi we agree that -Wall
should not reset -Wstrict-overflow. But of course final decision is up to iant.

------- Comment #5 From Manuel López-Ibáñez 2008-01-18 18:44 -------

*** This bug has been marked as a duplicate of 32102 ***

First Last Prev Next    No search results available      Search page      Enter new bug