[Python-Dev] Compiler warnings

[James Y Knight]

On Jan 31, 2006, at 8:16 PM, Tim Peters wrote:

> [Thomas Wouters]
>> I noticed a few compiler warnings, when I compile Python on my  
>> amd64 with
>> gcc 4.0.3:
>>
>> Objects/longobject.c: In function 'PyLong_AsDouble':
>> Objects/longobject.c:655: warning: 'e' may be used uninitialized  
>> in this function
>
> Well, that's pretty bizarre.  There's _obviously_ no way to get to a
> reference to `e` without going through
>
> 	x = _PyLong_AsScaledDouble(vv, &e);
>
> first.  That isn't a useful warning.


Look closer, and it's not quite so obvious. Here's the beginning of  
PyLong_AsDouble:
> double
> PyLong_AsDouble(PyObject *vv)
> {
>     int e;
>     double x;
>
>     if (vv == NULL || !PyLong_Check(vv)) {
>         PyErr_BadInternalCall();
>         return -1;
>     }
>     x = _PyLong_AsScaledDouble(vv, &e);
>     if (x == -1.0 && PyErr_Occurred())
>         return -1.0;
>     if (e > INT_MAX / SHIFT)
>         goto overflow;


Here's the beginning of _PyLong_AsScaledDouble:

> _PyLong_AsScaledDouble(PyObject *vv, int *exponent)
> {
> #define NBITS_WANTED 57
>     PyLongObject *v;
>     double x;
>     const double multiplier = (double)(1L << SHIFT);
>     int i, sign;
>     int nbitsneeded;
>
>     if (vv == NULL || !PyLong_Check(vv)) {
>         PyErr_BadInternalCall();
>         return -1;
>     }


Now here's the thing: _PyLong_AsScaledDouble *doesn't* set exponent  
before returning -1 there, which is where the warning comes from.  
Now, you might protest, it's impossible to go down that code path,  
because of two reasons:

1) PyLong_AsDouble has an identical "(vv == NULL || !PyLong_Check 
(vv))" check, so that codepath in _PyLong_AsScaledDouble cannot  
possibly be gone down. However, PyLong_Check is a macro which expands  
to a function call to an external function, "PyType_IsSubtype((vv)- 
 >ob_type, (&PyLong_Type)))", so GCC has no idea it cannot return an  
error the second time. This is the kind of thing C++'s const

2) There's a guard "(x == -1.0 && PyErr_Occurred())" before "e" is  
used in PyLong_AsDouble, which checks the conditions that  
_PyLong_AsScaledDouble set. Thus, e cannot possibly be used, even if  
the previous codepath *was* possible to go down. However, again,  
PyErr_BadInternalCall() is an external function, so the compiler has  
no way of knowing that PyErr_BadInternalCall() causes PyErr_Occurred 
() to return true.

So in conclusion, from all the information the compiler has available  
to it, it is giving a correct diagnostic.

James