Hi Dave (with a question for Andrew at the end): > On Dec 18, 2010, at 6:30 PM, Alan W. Irwin wrote:
>> With plgnfnam that would be changed to something like >> >> (needed_size, fnam) = plgnfnam(100) >> if needed_size >= 100: >> # Oops, 100 was too small. >> fname = plgnfnam(needed_size+1)[1] > > This is an example of why I like to hand code language bindings. IMHO, the plgnfnam function, if it is even exposed in the scripting language, should take no arguments and always return a string containing the entire contents. Why make the user provide an initial guess? This requires them to check whether their guess was big enough and try again (without forgetting the "+1") if it wasn't. How inconvenient! Good points. Hiding details is always good so I think we should do this. So far I think we are in consensus, but now I have had one more thought that would change the proposed API to be quite different than strlcpy. (Sorry about that!) That thought is if information hiding is good for high-level languages, why not do that at the C level right from the start? In other words, after this large sidetrack I have come to the conclusion that we should use Andrew's idea to alloc sufficient space inside plgnfnam, etc. to hold the string. After all, we can use strlen to determine the lengths of the version, device, and filename strings for a particular stream so allocing inside the routines with the exact size required seems like a good idea to me with no worries about initial guesses for the size, reallocating, etc. So the API would look like the following (dropping n from the name with its mental association with a size argument and putting a 1 on the end instead to differentiate this new set of routines from the deprecated versions): char * plgfnam1(void); So a typical use fragment would be the following. (I hope I have gotten this right because I still often screw up C pointers due to my lack of experience with C other than my contributions to PLplot). char * fnam; fnam = (char *) plgfname1(); fprintf( stdout, "PLplot file name: %s\n", fnam ); free(fnam); And for Python, the call would be fnam = plgfnam1() or fnam = plgfnam() (which would be exactly equivalent to plgfnam1) with all details about the C level call to plgfnam1() and freeing the buffer after the string is copied to the Python level hidden in the swig-generated interface. And similarly for the other high-level languages. Andrew, is that what you had in mind from the get go? Dave, do you see any downsides to the above idea as I have fleshed it out? 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
