Re: [Plplot-devel] Problem builiding the Python bindings on Windows using MS VC/C++

[Andrew R. <and...@us...>]

I now understand why the code is different. The typemap for mapform_func 
mapform has a default clause which controls what happens if the argument is 
omitted. It seems that once swig has encountered an optional argument all 
subsequent arguments are also counted as optional so are wrapped with an if 
statement. The subsquent arguments do not have a default value though, hence 
the uninitialized variable warning. If the function is correctly called then 
the variables _will_ be defined, but if not then it would cause an error.

To see this just comment out the lines 

// you can omit the mapform func
%typemap( default ) mapform_func mapform {
    python_mapform = 0;
    $1             = NULL;
}

in plplotcmodule.i and all will compile without warnings. It seems that plmap 
and plmeridian are the only functions where one of these callback functions is 
used early on in the option list before other more standard options. 

I'm not sure quite what the best way of fixing this is. It seems like a swig 
"feature". One could probably work round by including a default statement for 
every typemap, but we don't particularly want to do that. Ideas Alan?

Andrew

On Monday 21 Oct 2013 22:11:50 Andrew Ross wrote:
> Alan,
> 
> Firstly, the rounding issues are not an intrinsic 32-bit issue. With a
> 32-bit version of Debian unstable (running under pbuilder) I get completely
> clean results for make test_diff_psc, with the exception of stdout for the
> python example 23. This is with python 2.7.5.
> 
> Compiling plplotcmodule with -O3 -Wuninitialized I get the same warnings for
> plmap and plmeridian that Alan reports. From the swig generated code it is
> clear why this is the case. The arg variable initialization code is
> surrounded by some if statements. What is not at all clear is why swig
> generates different code for this case compared to the other functions. I
> will continue to delve further.  (Swig version 2.0.10).
> 
> Andrew
> 
> On Sunday 20 Oct 2013 21:50:21 Alan W. Irwin wrote:
> > Hi Andrew:
> > 
> > We need further followups from you when you can find the time.
> > 
> > More details below in context.
> > 
> > On 2013-10-19 22:09-0700 Alan W. Irwin wrote:
> > > On 2013-10-19 12:53-0700 Alan W. Irwin wrote:
> > >> Well, there are 74 such instances.... [in the make.out generated by
> > > 
> > > MSVC].
> > > 
> > > It turned out that -O0 -Wuninitialized picked up those 74 issues as
> > > well (on Linux).  So I fixed those (revision 12611). None of those
> > > were false alarms, but they all concerned the fail: path, i.e.,
> > > whenever the python PLplot wrapper function was called with a bad
> > > argument, so potentially could have created extra real issues for that
> > > case.
> > > 
> > > I have since discovered that -O3 -Wuninitialized shows additional
> > > issues in the bindings/python/plplotcmodulePYTHON_wrap.c file
> > > generated in the build tree by swig.  These are less obvious to fix,
> > > but I plan to work on that first thing tomorrow (Sunday). All the
> > > above was tested with 64-bit Linux with no run-time issues when
> > > generating python results and no differences between those and the C
> > > results (which is expected since that has been the case for a while).
> > 
> > I fixed one of those concerning the legline argument of plstripc
> > (revision 12613) but there are two other sets of uninitialized
> > variables concerning the arguments of the c_plmeridians and c_plmap
> > calls where there is a problematic style where certain error
> > conditions can just drop through to the calls of the functions causing
> > uninitialized arguments.  Of course, this is not a problem for our tests
> > because we don't make any errors in the calls to plmeridians or plmap.
> > But this problematic style might cause a nasty surprise for users who
> > do have some errors in the arguments to those python routine.
> > 
> > @Andrew: I cannot figure out what causes the change to this
> > problematic style generated by swig for how the floating point
> > arguments are treated for those two functions, compared to the good
> > style used for (say) the floating-point arguments of plenv.  Since
> > plmeridians and plmap are the only functions that use the mapform
> > callback, I suspect the typemap for it is somehow screwing up the
> > style for these functions, but that is as far as I can take this.
> > Would you be willing to take a further look using the warning messages
> > generated by gcc -O3 -Wuninitialized? (Note, I got these
> > compiler warnings about the potential uninitialized arguments
> > for c_plmeridans and c_plmap for both the 64-bit Linux platform and the
> > 32-bit MinGW/MSYS/Wine platform when gcc -O3 -Wuninitialized was used.)
> > 
> > > I am holding off on testing anything on MinGW/MSYS/Wine until the
> > > Linux -O3 -Wuninitialized result is free of warnings for
> > > bindings/python/plplotcmodulePYTHON_wrap.c.  Of course, I am not sure
> > > that any of this work will solve the python-C comparison issues for
> > > MinGW (and possibly gcc) on 32-bit systems, but I feel it is a good
> > > idea to systematically get rid of all "obvious" uninitialized warnings
> > > this way just in case one of them does affect that issue.
> > > 
> > > I also fixed (I hope, since gcc does not warn about it) the following
> > > warning in your make.out file:
> > > 
> > > D:\plplot-svn\plplot\drivers\ps.c(599) : warning C4244: 'initializing'
> > > 
> > > : conversion from 'PLFLT' to 'int', possible loss of data
> > > 
> > > What I did in that case was convert all the macros used for such
> > > comparisons to floating point numbers. (revision 12611).
> > 
> > The MinGW/MSYS results are better for me now.
> > The remaining list is
> > 
> > python
> > 
> >    Missing examples            :
> >    Differing postscript output :  00 03 04 05 06 08 09 11 12 14a 15 16 17
> >    18
> > 
> > 20 21 22 23 25 26 27 29 33 Missing stdout              :
> >    Differing stdout            :  23
> > 
> > where 19 is now perfect and all of the ones with differences are
> > usually 0.01 per cent.  The exceptions are example 17 and 25 with
> > large differences according to ndiff (but I cannot see anything
> > visually) and example 20 with 1 per cent maximum differences (having
> > to do with color settings) according to ndiff.  (The previous run I
> > had large differences for 17, 20, 22, and 25.)
> > 
> > Every improvement to the Python interface I have made between the two runs
> > can be classified as removing uninitialized variables from failure paths
> > not executed by our standard examples.  So I am pretty sure these
> > improvements are because I am currently using gcc -O3 while the results
> > before were derived with gcc with no optimization (-O0). That result (and
> > the lack of any effect for MSVC) is still consistent with the
> > uninitialized
> > variable hypothesis since the two gcc optimizations and the different MSVC
> > compiler will all execute code in very different orders with a different
> > memory footprint.  The result is the uninitialized variable would be moved
> > around in the memory so it is affected by different bit patterns.
> > 
> > @Andrew: I think Arjen and I have done as much as we can do here
> > so I hope you are willing to follow this up with further investigation
> > especially if you can confirm the 32-bit gcc troubles on Linux
> > as well.
> > 
> > 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
> > __________________________
> > 
> > --------------------------------------------------------------------------
> > -- -- October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > from the latest Intel processors and coprocessors. See abstracts and
> > register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktr
> > k
> > _______________________________________________
> > Plplot-devel mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
> 
> ----------------------------------------------------------------------------
> -- October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel