Sprach: Morten Welinder <terraat_private>: > A recent article on BugTraq suggested that using strcpy should > almost always be considered a bug. That's not right. It is, > in fact, the wrong way around: strncpy is almost always a bug. [...] > 1. Different parts of a program can assign different meanings as > a file name to the same string because they truncate at different > lengths. (Since a program might pass on a file name to a sub- > process, such different lengths need not be in the same program.) [...] 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 sinsterat_private Unsolicited commercial email will be archived at $1/byte/day. When cryptography is outlawed, only outlaws iernl 8ujke, ]jbsmwuns q*ud Howie Goodell
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:43:42 PDT