On Fri, Dec 17, 2010 at 10:53:44AM -0800, Alan Irwin wrote:
> 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.
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.
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. Down side for us is that allocated memory
in C may be difficult to use in other languages.
>
> 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).
Andrew
------------------------------------------------------------------------------
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
