From: Alan W. I. <ir...@be...> - 2013-10-19 19:53:23
|
On 2013-10-19 18:48-0000 Arjen Markus wrote: > HI Alan, > > from a first glance, I think they are false alarms - they show up in clean-up code. But > that is only a preliminary conclusion from just a glance. Hi Arjen: Well, there are 74 such instances. I agree the first one for tmp8 seems to be associated with cleanup code for failure conditions associated with the fail: label. But that is worth fixing since if a Python user enters the wrong argument type, for example, we don't want the whole of python to segfault because of that uninitialized variable. And once that uninitialized variable result is fixed in bindings/python/plplotcmodule.i, it will automatically fix a significant fraction of the remaining 74 such instances in the code generated by swig. Which may leave some uninitialized variable in that code that has even bigger impact than the uninitialized variables in cleanup code for failure conditions that we have already identified. Or as you say this code cleanup might not have any impact on the different Python-C results we get for the MinGW compiler (and which Andrew might still be able to confirm for the closely related gcc compiler as well on 32-bit Linux.) But the code cleanup is worthwhile in its own right so let me have a first crack at that. I plan to use the -Wuninitialized' gcc option which is supposed to detect possible uninitialized variables. But if MSVC does a better job of detecting such conditions, I might need you to do another evaluation with it after I have fixed everything that is mentioned by the gcc -Wuninitialized' option for the Python interface. More later.... Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |