--- Dan Scott <[EMAIL PROTECTED]> wrote: > On 28/09/2007, Dan Scott <[EMAIL PROTECTED]> wrote:
<snip> > The attached patch replaces the first patch in the thread. In the > attached patch, I: > > a) replace bzero calls (bzero is deprecated) with calls to memset. > I'm > initializing the memory to '\0', feel free to change that to 0 if you > prefer. It is conceivable that, on some systems, bzero might be more efficient than memset, especially if it can use a specialized machine instruction. I haven't done any benchmarks to compare the two, and in any case such a benchmark would apply only to systems like mine. Apart from that hypothetical advantage, I know of no reason ever to use bzero instead of memset, since Standard C defines the latter and not the former. What's more efficient than either of them is neither of them. In my own code, I never bother to nul-fill a buffer, because in every case I would immediately overwrite the nuls with something else anyway. It's a waste of time to write to the same bytes twice. OSRF routinely relies on memset (buried in safe_malloc) to initialize member variables with zeros and NULLs. This policy is so deeply ingrained that I despair of ever removing the memset from safe_malloc or its macro equivalent. However I have been campaigning at least to initialize pointers explicitly to NULL, since all-bits-zero is not guaranteed to represent a NULL pointer. > b) replace, as much as possible, static lengths in memset & snprintf > calls with sizeof calls instead; this way, if we decide to change the > length of a given string, we only have to update the value in one > place. So instead of: <snip> I completely agree about the use of sizeof, where applicable. > c) removed calls to bzero() or memset() when the variable that was > being initialized is immediately being filled via snprintf() -- > snprintf() guarantees that the string will be terminated with NIL. I completely agree with the removal of memset or bzero immediately preceding snprintf. However I don't think it's true that snprintf always provides a terminal nul. As I understand it, it adds a terminal nul only when the formatted string is shorter than the buffer. If it's too long to fit, or if it fits exactly with no space left over, snprintf fills up the buffer with non-zero bytes and does not provide a terminal nul. There are various ways to deal with that possibility, but pre-filling the buffer with zeros is not one of them. > I'm sending this to the list rather than just committing it, because > it's been a few years since I've exercised my C skills in any > significant way and I would appreciate a once-over from others (like > Scott!). > > Would we be interested in migrating to safer functions like strlcpy > and strlcat in the future? <snip> I'm not familiar with strlcpy or strlcat but I'll take a look. Scott McKellar http://home.swbell.net/mck9/ct/
