[GRASS-dev] clean_temp rewritten

[Brad Douglas]

On Sun, 2006-06-25 at 10:37 +0100, Glynn Clements wrote:
> Paul Kelly wrote:
> > >>Unless there are any problems with G_asprintf() or reasons why it should
> > >>not be used I propose we change the above snprintf() occurences to use
> > >>G_asprintf().
> > > 
> > > 
> > > Paul,
> > > 
> > > I think you are right with "fairly" new (some months).
> > > I forgot to add Glynn's comment (to me):
> > > 
> > > On Tue, May 16, 2006 at 04:20:43AM +0100, Glynn Clements wrote:
> > > 
> > >>Changing the code to use G_asprintf() instead is one alternative
> > >>(although G_asprintf() uses a temporary file on systems which lack
> > >>asprintf()).
> > 
> > EXCEPT changes made on 30th Jan appear to change this functionality as 
> > far as I can see mean that G_asprintf() is *always* implemented using 
> > Eric Miller's temporary file method:
> 
> The current implementation uses vasprintf() if HAVE_ASPRINTF is
> defined (which is the case on my system; running "nm" on libgis lists
> vasprintf() as an imported symbol).
> 
> Personally, I suggest /not/ using G_asprintf() unless it's absolutely
> necessary (i.e. where you can't impose any sensible limit on the
> maximum length of the resulting string).
> 
> snprintf() is simpler to use and more efficient (even on systems which
> use vasprintf(); for systems using the tempfile hack, the difference
> is even more significant).
> 
> For systems lacking their own snprintf(), we can either use a
> third-party version, or just discard the length argument and use
> vsprintf().
> 
> If the code was otherwise robust against buffer overruns, then
> ignoring the length argument would be a genuine issue. However, there
> are probably hundreds of places where a buffer overflow could occur,
> so one more doesn't make that much difference.

I'd prefer to do it right once and forget about it, but implementing a
snprintf() clone is not a small task.  I asked to use a 3rd party
version some months ago, but it didn't really generate much discussion.

So what's the final word here?  It would be impractical to define
solutions for every case, but some general guidelines would clear up a
lot of confusion.

The nature of G_asprintf() and it's most likely legitimate uses should
be documented in docbook if it's going to continue to exist as it is.
It seems that a section could be added to docbook about dealing with
strings and what functions are "allowed" in GRASS.

If this issue can be more or less settled, I can do the documentation
(read: easy) part.


-- 
Brad Douglas <rez touchofmadness com>                      KB8UYR
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785