Jim Rees <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
