somenath said:
But my understanding was in pointer context 0 and NULL is converted to
null pointer. And converting to null pointer is compiler
responsibility. So I thought 0 in memset will be converted to null
pointer (which is system specific).
I would request you to correct me as I am feeling I may be
misunderstood some concept.
You need to separate two very different ideas - *value* and
*representation*. You are quite right that an assignment such as:
char *p;
p = 0; /* ...this... */
requires the compiler to assign p a null pointer value. Let's just assume
for the sake of argument that we're on a platform where a null pointer is
*not* all-bits-zero. In this circumstance, the compiler is obliged to do
any necessary magic to ensure that p ends up with a null pointer value as
a result of the assignment.
But memset is a very different thing indeed. It takes no account whatsoever
of value, and it doesn't know that what you've passed to it is the address
of the first of a bunch of pointers. All it knows is that it has to set a
bunch of bytes to such-and-such, starting at such-and-such an address and
continuing for so-many bytes. It cares about the value you pass only
insofar as it can be represented as an unsigned char, and it doesn't care
a jot about the value of the resulting object.
The memset function can be (isn't!, but can legally be) implemented like
this:
#include <stddef.h>
void *memset(void *s, int c, size_t n)
{
unsigned char *p = s;
while(n--)
{
*p++ = c;
}
return s;
}
As you can see, memset doesn't (and indeed can't) care what kind of
object's bytes it is hacking at, and so it can't distinguish between a
pointer value and some other kind of value. Thus, in the original code,
memset(&ptr[0], 0, n * sizeof *ptr); would merely have set the object
representation to all-bits-zero, without any attempt whatsoever to address
the question of which value the object would have afterwards.
