Tim Peters wrote:
>>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.
It inlines the function to make this determination. Now, it's not true
that e can be uninitialized then, but there the gcc logic fails:
If you take the
if (vv == NULL || !PyLong_Check(vv)) {
PyErr_BadInternalCall();
return -1;
}
case in _PyLong_AsScaledDouble, *exponent won't be initialized. Then,
in PyLong_AsDouble, with
x = _PyLong_AsScaledDouble(vv, &e);
if (x == -1.0 && PyErr_Occurred())
return -1.0;
it looks like the return would not be taken if PyErr_Occurred returns
false. Of course, it won't, but that is difficult to analyse.
> I don't know. Is this version of gcc broken in some way relative to
> other gcc versions, or newer, or ... ? We certainly don't want to see
> warnings under gcc, since it's heavily used, but I'm not clear on why
> other versions of gcc aren't producing these warnings (or are they,
> and people have been ignoring that?).
gcc 4 does inlining in far more cases now.
Regards,
Martin
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
