memset pointer to 0

[ImpalerCore]

Quick question. Is there a guarantee that memset a pointer to 0 will
be equivalent to assigning the NULL pointer? I think not, since there
can be systems where the null pointer is non-zero. Is this the only
reason why?

Thanks

 

[Keith Thompson]

Quick question. Is there a guarantee that memset a pointer to 0 will
be equivalent to assigning the NULL pointer?
No.

I think not, since there
can be systems where the null pointer is non-zero.

Right, assuming that "non-zero" refers to the representation.

Is this the only
reason why?

Probably. (I don't see that more than one reason is required.)

 

[ImpalerCore]

Right, assuming that "non-zero" refers to the representation.


Probably.  (I don't see that more than one reason is required.)

Followup question. If I have two pointers 'a' and 'b', and 'b' is set
explicitly to NULL, can I memcpy 'b' to 'a' and be guaranteed that 'a'
will be interpreted as NULL?

 

[Seebs]

Quick question. Is there a guarantee that memset a pointer to 0 will
be equivalent to assigning the NULL pointer? I think not, since there
can be systems where the null pointer is non-zero. Is this the only
reason why?

Pretty much. all-bits-zero is only guaranteed to be zero-like for
integers, as I recall.

-s

 

[Seebs]

Followup question. If I have two pointers 'a' and 'b', and 'b' is set
explicitly to NULL, can I memcpy 'b' to 'a' and be guaranteed that 'a'
will be interpreted as NULL?

Assuming they're the same type of pointer, I am pretty sure you are,
because you're assured that copying the bytes out of an object and
then back into it preserves it.

-s

 

[Keith Thompson]

Pretty much. all-bits-zero is only guaranteed to be zero-like for
integers, as I recall.

And that guarantee was added only in one of the Technical Corrigenda
to C99. The C99 standard itself allows for the possibility that
all-bits-zero could be a trap representation for an integer type.

 

[Nick]

From: Seebs <[email protected]>
Subject: Re: memset pointer to 0
Newsgroups: comp.lang.c
Date: 15 Apr 2010 19:56:34 GMT
Organization: Megabitz - More USENET, Faster USENET

Can you have a system where before storing or retrieving any pointer
value it is XORed with the address of the variable it's stored in? In
that case, all normal pointer operations would work (including comparing
two pointers to the same place) but if you read the bits directly they
would be different.

Never going to happen, of course.

 

[Nick]

Mostly no. The bits stored would be the "representation" of the
pointer, and certain classes of pointer types are guaranteed to have
compatible representations. So if you memcpy from the address of one
char* to the address of another char*, both char* will point to the
same char. It would be possible that in an implementation with 32 bit
address space a pointer is 64 bit, and the lower 32 bit contain the
address of the object pointed to, and the higher 32 bit contain the
address where the pointer is stored if you store it using an
assignment. Still, memcpy'ing a pointer would have to produce a valid
pointer again.

So if we have:
sometype x;
sometype *a, *b;
a = &x;
b = &x;

then
memcmp(a,b,sizeof(x))
has to return zero?

You say "certain types". I assuming this is true when sometype is char,
which others is it true for?

 

[Ersek, Laszlo]

So if we have:
sometype x;
sometype *a, *b;
a = &x;
b = &x;

then
memcmp(a,b,sizeof(x))
has to return zero?

Didn't you mean

sometype x;
sometype *a, *b;

a = &x;
b = &x;

memcmp(&a, &b, sizeof a);

?

Answering your verbatim question: of course memcmp() has to return zero,
because it compares the representation of object x against the
representation of the same object x.

memcmp(&x, &x, sizeof x);

Answering your question the way I think you've actually meant it: not
necessarily. Identical representations imply equality by "==" (if "==" is
allowed at all in the specific case), but "==" evaluating to 1 doesn't
imply identical representations. Perhaps your (fixed) example above does,
but in general, if you get two objects of type T that are valid at that
point to compare with "==", and "==" evals to 1, memcmp() can still return
nonzero. Or so I seem to remember the standard.

.... See C99 6.2.6 Representations of types, 6.2.6.1 General, paragraph 8:

----v----
Where an operator is applied to a value that has more than one object
representation, which object representation is used shall not affect the
value of the result. 43) Where a value is stored in an object using a type
that has more than one object representation for that value, it is
unspecified which representation is used, but a trap representation shall
not be generated.
----^----

Footnote 43:

----v----
It is possible for objects x and y with the same effective type T to have
the same value when they are accessed as objects of type T, but to have
different values in other contexts. In particular, if == is defined for
type T, then x==y does not imply that memcmp(&x, &y, sizeof (T)) == 0.
Furthermore, x==y does not necessarily imply that x and y have the same
value; other operations on values of type T may distinguish between them.
----^----

Cheers,
lacos

 

[ImpalerCore]

Assuming they're the same type of pointer, I am pretty sure you are,
because you're assured that copying the bytes out of an object and
then back into it preserves it.

Are there systems where using two or more different pointer sizes is
common (maybe akin to the 'far', 'near' modifiers)? If so, does the
size of void* refer to only one specific pointer size within that
system?

 

[Seebs]

Are there systems where using two or more different pointer sizes is
common (maybe akin to the 'far', 'near' modifiers)? If so, does the
size of void* refer to only one specific pointer size within that
system?

Yes, it does. All (void *) must be the same size and representation.

You could have qualifiers like __far void * or __near void *, but a
type has to have a fixed size and representation.

-s

 

[Andrey Tarasevich]

So if we have:
sometype x;
sometype *a, *b;
a = &x;
b = &x;

then
memcmp(a,b,sizeof(x))
has to return zero?

No. Pointer types can contain padding bits in their object
representation. The combination of padding bit values is not required to
be determined by the value-forming bits, meaning that 'a' and 'b' can
contain different bit patterns in their padding bits, thus making the
`memcmp` to return non-zero result.

 

[Andrey Tarasevich]

Are there systems where using two or more different pointer sizes is
common (maybe akin to the 'far', 'near' modifiers)? If so, does the
size of void* refer to only one specific pointer size within that
system?

C FAQ offers some examples

http://c-faq.com/null/machexamp.html

 

[Richard Bos]

So if we have:
sometype x;
sometype *a, *b;
a = &x;
b = &x;

then
memcmp(a,b,sizeof(x))
has to return zero?

No. That's the other way 'round. It is legal for two pointers with
different representations to have the same value - i.e., point at the
same object. Of course, an implementation would have to go out of its
way in a desire to be perverse, for you to actually get anything but
zero in the above example; but it is legal.
What this thread was talking about is the other way 'round. If you have

sometype x=someval;
sometype *a, *b;
a=&x;
memcpy(&b, &a, sizeof b);
if (a==b)
puts("Equal");
else
puts("Unequal");
if (*a==*b)
puts("Equal");
else
puts("Unequal");


then that must print "Equal" twice.

Richard

 

[Jon Du Kim]

Quick question. Is there a guarantee that memset a pointer to 0 will
be equivalent to assigning the NULL pointer? I think not, since there
can be systems where the null pointer is non-zero. Is this the only
reason why?

Please note that for maximum backwards compatibility to
older systems you should use bzero().
You should always ensure your code can run on
even old implementations.
Be careful this is the sort of thing
you can dinged on here.

 

[Keith Thompson]

Please note that for maximum backwards compatibility to
older systems you should use bzero().
You should always ensure your code can run on
even old implementations.
Be careful this is the sort of thing
you can dinged on here.

Jon Du Kim is ... mistaken. bzero() is not defined by the
C standard; memset() is. There are probably some very old
implementations that support memset() but not bzero(), but you're
very unlikely to run across any of them. On the other hand,
you're more likely to run into a system that supports memset()
but not bzero().

 

[Nick Keighley]

Please note that for maximum backwards compatibility to
older systems you should use bzero().
You should always ensure your code can run on
even old implementations.
Be careful this is the sort of thing
you can dinged on here.

do you have access to a system for which this is true?

 

[Seebs]

Please note that for maximum backwards compatibility to
older systems you should use bzero().

No, you shouldn't. bzero() is a Berkeleyism.

You should always ensure your code can run on
even old implementations.

I really simply don't care about implementations which lack memset,
and even less about the tiny subset of implementations which lack memset
and have bzero.

-s

 

[Nick Keighley]

No, you shouldn't.  bzero() is a Berkeleyism.


I really simply don't care about implementations which lack memset,
and even less about the tiny subset of implementations which lack memset
and have bzero.

and besides a basic memset() isn't hard to implement on whatever wierd
system it isn't available on

 

[Phil Carmody]

Quick question. Is there a guarantee that memset a pointer to 0 will
be equivalent to assigning the NULL pointer? I think not, since there
can be systems where the null pointer is non-zero. Is this the only
reason why?

[Troll crap]

Jon Du Kim is

posting from aioe.org. Just sayin'.

Phil