[4964] in bugtraq
Re: better snprintf replacement, anyone?
daemon@ATHENA.MIT.EDU (Steve \"Stevers!\" Coile)
Tue Jul 22 00:19:33 1997
Date: Mon, 21 Jul 1997 08:05:34 -0400
Reply-To: "Steve \"Stevers!\" Coile" <scoile@PATRIOT.NET>
From: "Steve \"Stevers!\" Coile" <scoile@PATRIOT.NET>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199707200203.UAA26223@cvs.openbsd.org>
On Sat, 19 Jul 1997, Theo de Raadt wrote:
>Quite often I find people saying to me "Why do you use snprintf() all
>over the place to avoid buffer overflows, and not try to use other
>techniques. Using snprintf() makes it hard for us to port the code to
>legacy systems."
It's still not clear to me why people only suggest snprintf().
I would imagine that there are only a few cases were a program coulnd't
pre-determine the length of a string that would be generated by sprintf()
and malloc() enough memory to contain it all. Yes, it's a little extra
work to strlen() all the variables you're pulling in, but you ensure that
you have a large enough buffer, you eliminate the buffer overflow problem,
and you don't truncate the string. Is malloc()-ing the memory *that*
inefficient? Less efficient than the scanning and parsing snprintf()
must do to the format string?
--
Steve Coile P a t r i o t N e t Systems Engineering
scoile@patriot.net Patriot Computer Group (703) 277-7737
