On 2011-03-14 21:47-0000 Andrew Ross wrote: > > Alan, > > No - gcc is correct in warning about this, at least for C. An explanation > is given at > http://c-faq.com/ansi/constmismatch.html > > The problem is with the way C (and C++) define 2-d arrays as a pointer to > an array of pointers. const PLFLT **z only guarantees that the values of > z don't change, but allows the array of pointers to be modified.
Hi Andrew: Thanks for finding the above URL. It took me some rereads, but I think I understand it now. What is being demonstrated by the example at the above URL is that conversion from type ** to const type ** might allow additional subtle errors to creep in which are not possible with a conversion from type * to const type *. So the C/C++ standard demands (via warnings for C and errors for C++) that explicit casts must be used to convert type ** to const type ** not only in assignment statements (I can accept that) but also for arguments to functions (I am not happy with that). I took special exception to the last paragraph of the above article in the context of function arguments: <quote> In C, if you must assign or pass pointers which have qualifier mismatches at other than the first level of indirection, you must use explicit casts (e.g. (const char **) in this case), although as always, the need for such a cast may indicate a deeper problem which the cast doesn't really fix. </quote> I absolutely hate this sort of "prior restraint" for function arguments. Obviously, when we advertise an argument to one of the PLplot functions as const PLFLT ** (or const PLFLT * for that matter) we are making promises not to screw up by changing those array values. However, the whole thrust of the above URL is there is a subtle extra possibility for us to screw up in the doubly dimensioned case so our users must use make-work explicit casts (inconsistently in the doubly dimensioned case, but not in the singly dimensioned one) to remind them of the possibility that we _might_ be falsely advertising. And those explicit casts don't protect them in the slightest if we do screw up. I am not happy with this situation (to strongly understate the case), but I guess all C/C++ programmers are stuck with this "standard". I still feel it is the right thing to do to advertise that we don't change the values of our singly or doubly dimensioned array arguments. However, when discussing the const modifier API change in README.release I will refer to the above URL to try to avert the wrath of our users because of this extra explicit casting work that will be required from them from now on by the C/C++ standards. Alan > > On Mon, Mar 14, 2011 at 01:54:56PM -0700, Alan Irwin wrote: >> To the C/C++ gurus here: >> >> Because of all the gcc warnings and g++ errors (more about that later) >> I was getting unless I used explicit casts with e.g, const PLFLT ** >> arguments I became concerned that perhaps I was misinterpreting the >> meaning of >> >> const PLFLT ** z; >> >> Some googling this morning found the answer at >> http://stackoverflow.com/questions/336585/what-does-a-const-pointer-to-pointer-mean-in-c-and-in-c >> The discussion there pointed to >> http://c-faq.com/decl/spiral.anderson.html which I think you will all >> find an interesting read. Both sources confirm my original >> interpretation was correct. >> >> The answer is z is a mutable pointer to a mutable pointer to an >> immutable PLFLT. Therefore, such declarations for our function >> arguments claim that our functions are not changing the values of the >> doubly dimensioned z array which I believe is exactly what we want. >> Similarly, >> >> const PLFLT *x; >> >> arguments for our functions claim that our functions are not changing >> the values of the singly dimensioned x array which again I believe is >> exactly what we want. >> >> The above is useful background to the fundamental issue that bothers >> me which is automatic casting from mutable to immutable of singly >> dimensioned and doubly dimensioned arrays are treated quite >> differently by both gcc and g++. >> >> For an example of this with plline3, see examples/c/x18c.c where >> mutable x, y, and z singly dimensions array arguments are >> automatically cast to immutable without a warning message. I think >> that lack of warning message is the correct thing to do since >> obviously x, y, and z must be assigned values before calling plline3 >> so it makes no sense for gcc to warn about the automatic casting of >> each of those PLFLT * arrays to const PLFLT *. However, such sanity >> does not prevail for the doubly dimensioned array case; there you must >> explicitly use (const PLFLT **) casts to avoid warning messages from >> the gcc C compiler and error (!) messages from the gcc C++ compiler >> for the doubly dimensioned arrays, see examples/c/x11c.c and >> examples/c++/x11.cc. >> >> Does any C/C++ guru here know how to avoid those explicit casts for >> each of our doubly dimensioned arguments? I don't think I should >> revert the const project since there are reasons of documentation and >> safety to justify it (see >> http://www.cprogramming.com/tutorial/const_correctness.html). >> Nevertheless, if those explicit casts are required it will be >> inconvenient for our users so if it is possible to avoid that work, >> let's help at least our new users out with good examples. >> >> Note, this doubly dimensioned issue may be just a quirk with gcc and >> g++ being inconveniently restrictive about automatic casting from >> PLFLT ** to const PLFLT** without a warning (gcc) or error (g++) >> message, and other C and C++ compilers may have different quirks or >> errors concerning the interpretation of const. So it would be a good >> idea for those here with access to non-gcc compilers to run the >> test_diff_psc target with BUILD_TEST=ON and report back all warning or >> error messages that are related to our const arguments. >> >> Better to find out now about any platform problems introduced by the >> const modifier project rather than one day after our next release! >> >> 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); PLplot scientific plotting software >> package (plplot.org); 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 >> __________________________ >> > __________________________ 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
