Hi Alan, I made the mistake of replying to your first message, misinterpreting your warning - early morning, you see. Anyway, here is my answer:
On 2012-02-01 03:19, Alan W. Irwin wrote: > Hi Arjen: > > Could you comment on this bug report on list (as well as the bug > tracker)? > > Is it really a violation of Fortran standards if the LHS array bounds > are larger than the RHS array bounds? I don't have much Fortran 95 > experience, but I had assumed before reading this bug report that such > assignments would just fill in part of the LHS array corresponding to > the bounds of the RHS array and leave the rest of the LHS array > undefined, but the bug report refers to a URL which implies such bound > mismatches might lead to issues for some compilers. Is that because > the compilers are at fault or are bounds mismatches a real violation > of the Fortran standards? > It is a violation of the standard. For F2003 there is a new feature that allows you to relax this a bit for allocatables (and pointers, I guess, but I am not 100% sure) on the lefthand side: they get reallocated to the right size. My fix is: xg1(1:NPTSX) = ... yg1(1:NPTSY) = ... so that only the relevant part of the array is filled. The call to plcont() contains explicit array bounds and uses the size() intrinsic to pass the actual array dimensions to the underlying routines (plcon07() and related ones, depending on the exact argument list). I traced the calling sequence back to plfcont(): it does check the bounds as passed via the argument list for consistency. I have not checked if it is possible to pass the _wrong_ array dimensions or sections and get away with it (up to an access violation). It might be a good idea to do the checking up front, at the Fortran level, as then we can report the correct routine name (plcont instead of plfcont) and be sure that no such violation is even possible. > The other issue is that even if I am right and such assignments are > allowed, there may still be a bug because the underlying PLplot > library could potentially get the wrong size for the defined part of > the array. If by chance we are accidentally avoiding that bug because > another array is used to set the array size processed by PLplot, > perhaps you should put in some array-size consistency checks into the > Fortran 95 bindings similar to what we have for all the swig-generated > bindings, and use that check to discover and eliminate all cases where > there are currently mismatches in array bounds. > These extra checks will make the interface more robust, though the present checks might already do the job properly. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
