On Tue, Oct 11, 2011 at 03:57:43PM +0100, Andrew Ross wrote: > > I have taken an initial look at this. It's a whole can of worms! > > Firstly, I can reproduce your java crashes with openjdk or sun jdk but > not with gcj. This is a little odd. The backtraces are not entirely > helpful but it appears to be related to fprintf calls in the C part of > the bindings. It is also not entirely reproducible, i.e. the same > example won't segfault every time. A better start is probably to work > through the huge number of compiler warnings. > > Aside from the java issues there are a number of other issues I > encountered. Several parts of plplot use features which are POSIX > standard, but not part of the 1999 ISO C standard. strdup is one > example, also some of the signal handling in xwin / tk drivers. The > latter is not an issue since these drivers are only available on Unix > like systems anyway. This just makes it a pain to compile since either > we add compiler defines to allow posix features for the whole compile > (not ideal) or we need to add specific compile flags for specific files > which is not too easy in cmake (at least not in a quick and dirty way). > > FFLAGS is used for both f77 and f95 compiles which makes it hard to > tailor the flags for different standards. Again, it is a limitation > of cmakes handling of these things. > > In terms of the warnings themeselves, there are a lot related to > implicit casting of int / uint / size_t. We can make this clean > either by being consistent about types (best, but intrusive) or > by explicit casting (which hides the problem! - but in most cases > we know it is ok anyway). > > There are also warnings about assigning constant strings to non-const > char * arrays. On the whole changing to const char * fixes this and is > relatively straightforward. > > We don't always use prototypes for functions. Again, this is relatively > easy to fix if we feel it is serious enough. It is probably good form > to do so anyway. > > Unused parameters appear in a fair number of places. In function > definitions I would tend to leave these in for clarity, even if they > are not strictly necessary. > > Possibly uninitialized variables also appear. In all the cases I've > looked at they were actually ok, but were defined inside some > if ... else ... statements which the compiler cannot analyse to > check they are set. Probably good form to set them explicitly to > some default / null value to avoid future problems. The recent issue > Alan found with qsastime is a good example of this. > > A number of external libraries we use (e.g. wxwidgets, cairo, python) > have headers which are not clean. A favourite seems to be using "long long" > which is not in ISO C++ 1998. Hard to do much about this. > > SWIG generated code is not very clean, which again might be tricky to > deal with. > > Lots of examples of local variables shadowing a global variable or > typedef. Probably safe, but generally not good practice. > > So, in short there are some possible real issues and a fair bit of noise. > I've started some work tidying up bits of the code, but I certainly won't > commit anything until after the next release as it is going to be pretty > intrusive. Once I've cleaned up the easy parts, we can discuss what to > do about the more tricky warnings.
I've committed the first tranche of fixes for compiler warnings. For reference I've been testing with CFLAGS="-O3 -std=c99 -pedantic -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings" CCFLAGS=-O3 -fvisibility=hidden -std=c++98 -pedantic -Wall -Wextra FFLAGS=-O3 -fvisibility=hidden -pedantic -Wall -Wextra When required I have (by hand) added -D_POSIX_C_SOURCE=1 to the flags for specific files (e.g. xwin.c) in order to compile. So far this is just the easy to fix issues (function prototypes, missing braces, missing const for char *, shadowed variables, unused functions.) This is quite intrusive, so please test well. There will be more to come. So far I've not even looked at the issues related to casting variables between different types or at fortran. If someone with more fortran insight wants to take that on it would be good. I've also not looked at the java issue. Andrew ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
