[OpenAFS] sprintf -> snprintf...

Russ Allbery rra@stanford.edu
Thu, 26 Jun 2003 11:13:28 -0700


Jim Rees <rees@umich.edu> writes:

> Sounds like you are a snprintf expert.  You want to take a look and
> decide what to do?

Here's my opinion based on my cleanup of INN; take it with a grain of
salt, as I'm not very familiar with the OpenAFS code, but it seems to have
worked for us so far (and INN was full of a lot of really old, crufty code
that used strcpy and sprintf all over the place).

I think the exercise of eliminating use of strcpy, strcat, and sprintf is
very worthwhile, as they're inherently dangerous.  strncpy is *not* a good
replacement; it does various things that you don't want, like not
nul-terminating if the string is the size of the buffer and filling the
rest of the buffer with nuls even if it doesn't need to.  In fact, I
generally prefer to remove strncpy as much as possible as well.

What I did was add snprintf, strlcpy, and strlcat implementations using
AC_REPLACE_FUNC and the snprintf probe that I sent in another message and
then went through and changed (nearly) every call to sprintf to snprintf,
strcat to strlcat, and strcpy to strlcpy.  I also changed nearly all
strncpy and strncat instances to strlcpy and strlcat.  There's still some
remaining cruft to clean up, but it's mostly done and debugged at this
point.

For kernel code, it's trickier since it's hard to probe for what's already
available, but you can just always use afs_strlcpy, afs_snprintf, etc. and
then at least be guaranteed that all of your problems are your own.

I have public domain strlcat and strlcpy implementations with test suites
if you want them.  I also have an snprintf test suite if you'd like it.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>