[OPEN-ILS-DEV] Re: PATCH: bzero is deprecated and unnecessary

[Scott McKellar]

--- Dan Scott <denials at gmail.com> wrote:

> On 28/09/2007, Dan Scott <denials at gmail.com> 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/