On 2010-12-16 21:15-0800 David MacMahon wrote:
> Hi, Alan,
>
> On Dec 16, 2010, at 6:54 PM, Alan W. Irwin wrote:
>
>> Here is what I propose instead of this temporary measure. We go with
>> a backward-incompatible API change (and associated soname bump to
>> force everybody to recompile) of
>>
>> c_plgfnam( char *fnam ); ==> c_plgfnam( char *fnam, PLINT n);
>>
>> where n is the size of the buffer that has been allocated.
>> Internally, c_plgfnam will use n for the strncpy call as well as
>> figuring out the last byte to zero.
>>
>> Note, the other two PLplot functions (plgver and plgdev) that return
>> character strings have recommendations in the documentation to
>> allocate 80-byte buffers to contain the version string and device
>> name.
>
> I notice that all of these functions currently have a null return
type. One approach I've seen elsewhere, is to have functions like
this return an int indicating how many bytes were copied into the
buffer if the pointer given is non-null *or*, if the given pointer is
null, how many more bytes are needed to fill the buffer.
> This allows the client code to determine the buffer size needed,
(re-)allocate the buffer dynamically, then fill the buffer...
>
> bufsize = plgver(NULL, 0);
> buf = (char *)malloc(bufsize+1);
> plgver(buf, bufsize);
> buf[bufsize] = '\0';
>
> // Note how this can be used to determine
> // whether a buffer is already big enough
>
> extra = plgfnam(NULL, bufsize);
> if(extra > 0) {
> buf = (char *)realloc(buf, bufsize+extra+1);
> }
> bufsize += extra;
>
> // if extra < 0, bufsize will be smaller
> // than size of region allocated
> plgfnam(buf, bufsize);
> buf[bufsize] = '\0';
I very much like the general idea of using a returned value to always
allow changing the buffer size as appropriate. So many thanks for
bringing up this possibility, and I hope the result is we handle
these buffer size issues in an absolutely ideal way.
Furthermore, I have now changed my mind about two matters I discussed in
my previous post.
I now think we should prevent the soname bump (for now) by simply
deprecating plgver, plgdev, and plgfnam and adding new functions
called plgnver, plgndev, and plgnfnam that handle the buffer size
issue in an ideal way. My original thought was we wouldn't need
plgnver and plgndev. But now I think we do just based on the
interests of uniformity.
Of course, propagation of this new plgnver, plgndev, and plgnfnam
functionality to some languages might be tricky. I checked that for
our swig-based languages (Python, Java, and Lua), and I don't think it
will be a problem for that case. swig allows inserting arbitrary C
code such as the above allocs or reallocs into the interface. And it
is obviously not a problem to implement the new functionality in our
C++ language bindings. However, I would like all the language gurus
to think about implementing this new functionality for their favorite
language such as Ada (Jerry), D (Werner), Fortran 77, Fortran 95, and
Tcl (Arjen), OCaml (Hez), Octave (Andrew), and the externally
developed perl/PDL bindings (Doug Hunt who also lurks here).
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
