memset pointer to 0
ImpalerCore
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.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
ImpalerCore
> ImpalerCore <jadil...@gmail.com> writes:
> > 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.)
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
Pretty much. all-bits-zero is only guaranteed to be zero-like for
integers, as I recall.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Seebs
> 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.
Keith Thompson
> On 2010-04-15, ImpalerCore <jadi...@gmail.com> wrote:
> > 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.
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 <usenet...@seebs.net>
> Subject: Re: memset pointer to 0
> Newsgroups: comp.lang.c
> Date: 15 Apr 2010 19:56:34 GMT
> Organization: Megabitz - More USENET, Faster USENET
>
> On 2010-04-15, ImpalerCore <jadi...@gmail.com> wrote:
>> 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?
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.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
christian.bau
> 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?
Depends on the pointer types.
If both are void* or char* or unsigned char*, yes.
If both are pointer to a struct (even different structs), yes.
If both are pointer to a union (even different unions), yes.
If both are pointers to the same integer type except possibly for
signedness, yes
If both are pointers to the same floating-point type, yes.
But not if you memcpy for example from a float* to a double* or from a
pointer to a struct to an int* and so on.
christian.bau
> 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.
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.
christian.bau
> 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?
Depends on the pointer types.
Nick
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
> On 2010-04-15, ImpalerCore <jadil...@gmail.com> wrote:
>
> > 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.
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?
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Seebs
> On Apr 15, 3:56 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-04-15, ImpalerCore <jadil...@gmail.com> wrote:
>> 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?
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.
--
Best regards,
Andrey Tarasevich
Andrey Tarasevich
> On Apr 15, 3:56 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-04-15, ImpalerCore <jadil...@gmail.com> wrote:
>>
>>> 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.
>
> 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
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
Richard Heathfield
> On 2010-04-15, ImpalerCore <jadi...@gmail.com> wrote:
>> 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.
Either you have misread his question, or I have.
It seems to me that he is asking whether the following program is
required to print "Seebs is right":
#include <stdio.h>
#include <string.h>
#define ADJUST_TO_TASTE 1
int main(void)
{
void *a;
void *b = NULL;
size_t itisnotclearwhatvaluethisshouldbe = ADJUST_TO_TASTE;
memcpy(a, b, itisnotclearwhatvaluethisshouldbe);
printf("Seebs is %s\n", (a == NULL) ? "right" : "wrong");
return 0;
}
If the question is really about memcpy(&a, &b, sizeof a) then of course
you are correct.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Jon Du Kim
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
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().
Richard Heathfield
> ImpalerCore wrote:
>> 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().
Please note that following this rather unwise advice can break
compatibility with *existing* systems. All hosted implementations have
supported memset for over twenty years, but by no means all of them have
heard of bzero.
> You should always ensure your code can run on
> even old implementations.
And new ones.
> Be careful this is the sort of thing
> you can dinged on here.
Ding!
Nick Keighley
do you have access to a system for which this is true?
Seebs
> ImpalerCore wrote:
>> 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().
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.
Nick Keighley
> On 2010-04-19, Jon Du Kim <jo...@FAKE.EMAIL.net> wrote:
>
> > ImpalerCore wrote:
> >> 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().
>
> 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.
and besides a basic memset() isn't hard to implement on whatever wierd
system it isn't available on
Phil Carmody
> Jon Du Kim <jo...@FAKE.EMAIL.net> writes:
>> ImpalerCore wrote:
>> > 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?
>>
>
> Jon Du Kim is
posting from aioe.org. Just sayin'.
Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1