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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com