🚀 go-pugleaf

In article <823977867snz@wash.demon.co.uk>
	   john@wash.demon.co.uk "John Washington" writes:

[ interesting comments on Snews 1.29 and 1.30 ]
> ......  Ahah!  The problem with a long path is that,
> even though fgets() chops it and doesn't overflow
> 'buf', there's a sprintf() call that tacks your own
> host and domain on the front of the path, BUT WRITES
> THAT LONGER STRING INTO ANOTHER BUFFER OF THE ONLY THE
> SAME SIZE!
>
> It would be more economical, as well as safer, if
> buf2 (.5K in 1.29, 1K in 1.30) were not allocated
> until it's needed, and then made the exact length
> required.

Agreed.  buf2 is declared on the stack anyway, and the overhead
of a malloc/free is minimal.  I have no doubt that overflowing
buf2 'as is' will produce interesting and unpredictable
results...   However,

> sprintf() is a brain damaged library function.  Any
> function that writes into an array should have a
> parameter that gives the no. of elements of the
> array.  Sadly we have to live with sprintf, since
> it's defined in ISO C, but all calls to it should
> always be carefully reviewed.

Oh but it does, John - it's just that most of us (myself included)
generally don't bother, and in most cases doesn't produce the
desired result anyway :(  It's so much easier to write:
   sprintf (buf, "%s", p);
than
   sprintf (buf, "%-511.511s", p);

which will _guarantee_ you don't overflow a 512 byte buffer, but
presents you with the problem of removing the trailing spaces
which you might not want...

sprintf is a *wonderful* function - I couldn't live without it!
Someone has to defend it against such vicious attacks as the
poor abused routine can't defend itself :-)
--
Pete