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

Dan Scott denials at gmail.com
Sun Sep 30 01:03:26 EDT 2007


On 29/09/2007, Scott McKellar <mck9 at swbell.net> wrote:
>
> --- 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.

Well, we're thinking along the same lines then :)

> 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.

I can support your campaign; it's just going to take a while.

> > 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.

Actually, if I'm reading it correctly, C99 does guarantee the
null-terminating behaviour:

1         #include <stdio.h>
          int snprintf(char * restrict s, size_t n,
                  const char * restrict format, ...);

  Description
2 The snprintf function is equivalent to fprintf, except that the
output is written into
  an array (specified by argument s) rather than to a stream. If n is
zero, nothing is written,
  and s may be a null pointer. Otherwise, output characters beyond the n-1st are
  discarded rather than being written to the array, and a null
character is written at the end
  of the characters actually written into the array. If copying takes
place between objects
  that overlap, the behavior is undefined.

(Spec is at http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf)

> 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.

Thanks for the feedback, Scott!

-- 
Dan Scott
Laurentian University


More information about the Open-ils-dev mailing list