On Sat, Dec 03, 2011 at 09:51:29AM -0800, Alan Irwin wrote: > On 2011-12-03 09:01-0000 Andrew Ross wrote: > > > > > I have just committed a fairly large update to change the 2d arrays in > > our API from const PLFLT ** to const PLFLT * const *. Gcc warns about > > the use of const PLFLT ** because it only guarantees that the data is > > constant not the array of pointers to the data. It is therefore trivial > > to change the data by changing the pointers which is not what is > > intended. Both the pointer array and the data need to be marked const. > > > > This is quite intrusive, but it seems to work ok for me. Please check. > > It is strictly an API change however existing code should still > > compile fine (possibly with warnings depending on the gcc settings). > > > > This does not remove all warnings - just shifts them (more later). It > > does however make the API and the examples clean which I think is > > more important for users. > > > > The const PLFLT * const * is a bit unwieldy however, so I propose > > making a new typedef (something like PLFLT_2D_CONST) to tidy up > > the code. > > Assuming PLFLT is #defined like we have done, is "PLFLT * const *" > something all c99-compliant compilers should understand or is that > just a gcc extension? Even if the answer to that question is all > c99-compliant compilers should understand it, it is possible their c99 > implementations are buggy. Therefore, I think using a PLFLT_2D_CONST > typedef (which we could #define differently for any major > non-compliant compilers) might be a good idea from cross-platform > point of view as well.
This should be a standard feature. Of course, whether all compilers support it or not is another matter. I suspect they do. > For what it is worth, revision 12095 passes a limited test > (just test_noninteractive in the build tree) on my Debian stable platform > (gcc (Debian 4.4.5-8) 4.4.5). Furthermore, for that test using > > CXXFLAGS=-O3 -fvisibility=hidden > CFLAGS=-O3 -fvisibility=hidden > FFLAGS=-O3 > > there were no compiler warnings at all. That good result surprised me > because there used to be tonnes of Java warnings and a sprinkling of C > warnings. I don't know whether the Java warnings disappeared due to > your efforts, but in any case we have come a long way in getting our > code cleaned up thanks to your much appreciated efforts. That is good to know. I've been testing again with all the warning flags on. The new version of gcc (4.6) in debian unstable includes even more warnings. Usefully it also now includes details of which warning flags triggered the message. Incidentally, for testing with debian unstable I'm using pbuilder. It provides a clean chroot environment, primarily for building Debian packages, but you can also log in to test normal compiles etc. The big advantage over virtual machine approaches is that it is much lighter weight and quicker. Alan, you might want to look at this too. 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. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
