In your specific example of a file name, most (all?) operating systems
already impose a limit to the length of a file name. This limit is
therefore a natural maximum buffer size for all programs under that
operating system when dealing with file names: there is no justification
for being capable of handling longer file names, since it'll have to be
handed to the operating system eventually _anyway_, and limiting your file
names to a shorter length is an unnecessary restriction. Under Linux,
for example just #include <limits.h> and use PATH_MAX or NAME_MAX (as
appropriate).
But this argument carries to other types of buffers as well: in nearly
all cases there is some natural and clear limit to the size of the
data with which you need to deal. Properly written code will use
that natural limit. It's not reasonable to set all your buffers to
1024 bytes simply because "It's a nice power of 2."
So your argument against the use of strncpy is simply an argument against
using strncpy without thinking of your buffer sizes. But that's a
basic programming issue: use the library functions correctly. This
is a far cry from claiming that "strncpy is almost always a bug."
--
Jon Paul Nollmann ne' Darren Senn sinster@darkwater.com
Unsolicited commercial email will be archived at $1/byte/day.
When cryptography is outlawed, only outlaws iernl 8ujke, ]jbsmwuns q*ud
Howie Goodell