[GRASS-dev] clean_temp rewritten

[Glynn Clements]

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.

-- 
Glynn Clements <glynn at gclements.plus.com>