There are a few functions used to zero out memory on most unix variants. memset(), bzero(), and calloc() are all a few such functions. calloc() isn’t very useful for clearing already allocated memory, so it won’t be appearing much more in this article. However, the other two are somewhat more interesting than meets the eye.

On the surface, bzero() and memset() look similar enough to be related – bzero() being a special case of memset(). memset() takes 3 arguments, a pointer, a value, and a length. bzero(), on the other hand, omits the value parameter, since it’s implied to be zero.

The memset() function writes n bytes of value c (converted to an unsigned char) to the string s.

That conversion bit could mean that naive implementations operate a byte at a time – lousy for the wide register sizes of today. It’s trivial to combine that value a few times though, so hopefully that’s done?

bzero(), on the other hand, reports similar details:

The bzero() function writes n zeroed bytes to the string s.

So perhaps it’s in similar standing?

(At this point, I’m going to be rather open, and state that it’s almost 100% ridiculous to presume that a non-embedded c library would be so lame as to work with individual bytes in such a manner. It’s been known to happen, but I’m pretty sure that this isn’t the case on Linux, Windows, or Mac OS X (where testing takes place for this article)).

Firing up a debugger, we uncover some even more interesting information.

There’s that address again. 0xffff0600. There’s a bit more checking going on (expected, since memset()’s a bit more generic than bzero()), and a lot more happening afterwards, but for the value zero, it uses the same engine.

So, for cases where you know you’re going to zero out a block of memory, bzero() will be a bit more direct (avoiding the checking and what not). No profiling necessary, since it’s the same underlying algorithm.