Hi Andrew (with one question for Dave): Thanks for contributing to this discussion.
On 2010-12-18 13:59-0000 Andrew Ross wrote: > I think passing a buffer size is the safest way to go. If you wanted a > constant buffer length, then it should be PATH_MAX to ensure any path > will fit, but this still has risks associated. Agreed. > > Note other functions (e.g. getcwd - Linux extension) interpret a null > buffer differently, and will allocate a buffer using malloc in this > case to allocate a buffer. If the buffer size parameter > 0 then the > allocated buffer is of that size. If if is zero then a buffer big > enough to return the path is allocated. Note getcwd also returns null > if the buffer is not big enough and sets errno to ERANGE. > > I'm not necessarily suggesting this is better, but it an alternative > approach. Plus side is that it is easier for the user - allocations > are done automatically. Another model for plgnver, plgndev, and plgnfnam is one similar to strlcpy that is discussed by Todd C. Miller and Theo de Raadt at http://www.gratisoft.us/todd/papers/strlcpy.html. That is a most interesting paper to read. I am not necessarily advocating something similar to this model API. I leave that to those more knowledgable in C than I am. However, I am mentioning this paper for further discussion. <aside to Dave> Can you remember the name of the function you were using as the model for your API suggestion for plgnver, plgndev, and plgnfnam? If so, that will give us a chance to dig into the official documention of that function like we can currently do for getcwd and strlcpy. </aside to Dave> > Down side for us [of automatic allocation] is that allocated memory > in C may be difficult to use in other languages. Unless I misunderstood you, I think that allocation, possible reallocation, and free of a C buffer is a given (which I like) for all approaches discussed so far. For example, this is true for the getcwd Linux extension approach, the strlcpy approach, or Dave's approach. After the C buffer is filled with the character-string information from the PLplot core library, then it is up to each language interface to pass that information on to the language environment in appropriate form. That seems to be the model used in our swig-based language bindings and also for Tcl (if I am following that generated code correctly). My guess is our remaining language bindings follow that model as well. Regardless, they all currently implement plgver, plgdev, and plgfnam without issues so that means it should be possible to adapt those approaches to the plgnver, plgndev, and plgnfnam cases once we finalize the API for those. 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 __________________________ ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
