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