BSD bzero() & NULL

Barry Margolin barmar at think.com
Thu Nov 15 11:01:29 AEST 1990


In article <AbEJW8e00VQfE4N0I3 at andrew.cmu.edu> jl57+ at andrew.cmu.edu (Jay Laefer) writes:
>[I'm asking the following in the context of ANSI C.]
>
>I'm confused on an issue regargding NULL and the BSD function bzero().
>
>I realize that the following assignments are equal:
>
>char *fred;
>
>fred = 0;
>fred = (char *)NULL;
>
>because the compiler is responsible for translating the zero bit pattern
>into its internal representation of NULL.

Actually, the compiler translates between the *integer constant 0* and its
internal representation of NULL.  It doesn't do anything with bit patterns.
For instance, the following is not equivalent to the above:

int zero = 0;
fred = zero;

Because zero is an integer variable, not an integer constant.

>But, given that bzero() directly fills an area with zeros, can I assume
>that the following is equivalent to the above?
>
>bzero(fred, sizeof (char *))

I assume you meant:

bzero (&fred, sizeof (char *));

>My gut reaction is no because this zeros out a block of memory and I'm
>not guaranteed that the computer's internal representation of NULL is a
>zero bit pattern.

Your gut reaction is correct.  Bzero() stores a zero bit pattern, which is
not required to be equivalent to a null pointer.  Bzero() is just a library
function, so it isn't required to know the type of object that its argument
is pointing to, and therefore can't be expected to store the type-dependent
0 there.

The same may be true for floating point types, e.g.

float fl;
bzero (&fl, sizeof (float));

might not put 0.0 into fl.  Bzero can only be expected to work as expected
when the first argument is a pointer to an integral type.

--
Barry Margolin, Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar



More information about the Comp.lang.c mailing list