is a pointer memset to zero necessarily eqal to NULL?

[viza]

Hi all

Is this assertion guaranteed?
{
void *vptr;
memset( & vptr, 0, sizeof vptr);
assert( NULL == vptr );
}

What about these ones?
{
sometype *ptr;
memset( & ptr, 0, sizeof ptr);
assert( (sometype*)NULL == ptr );
assert( NULL == (void*)ptr );
}

Thanks,
viza

 

[Richard Tobin]

Is this assertion guaranteed?

No, none of them are. There is no necessary relation between a
pointer with all bits zero and a null pointer.

On the other hand, it's true on all widely-used platforms.

-- Richard

 

[viza]

No. It is not guaranteed that the internal representation of a null
pointer is 0xdeadbeef, even on a machine with 32-bit pointers. But it
might be.

Is there then some library function to set an array of objects of
size > 1 to the same value? Something like wmemset() but for things the
size of pointers, or even larger structs?

Thanks,
viza

 

[Kenny McCormack]

None of those.

These assertions are guaranteed:
{
void *vptr = 0;
sometype *ptr = 0;

assert( NULL == vptr );
assert( NULL == 0 );
assert( 0 == vptr );
assert( ptr == vptr );
}

As are these (and are equally relevant):

int three = 3;
assert(threee == 3);

char *peteIsMoron = "Yes, it is almost beyond belief what a turd he is";
char *yup = peteIsMoron;
assert(yup == peteIsMoron);

 

[Kenny McCormack]

The above two assertions are guaranteed to be true, but the next one
below, is guaranteed to generate a diagnostic message.

assert( ptr == zero );
}

Even more to the point:

#define three 3
assert(three == 3);

 

[Peter Nilsson]

Have you tried reading the FAQ?

Is there then some library function to set an array of
objects of size > 1 to the same value?

Where does the size come into it?

Just use a loop...

static const struct foo foo_zero; /* zero initialised */
for (i = 0; i < N; i++)
array = foo_zero;

 

[Keith Thompson]

Where does the size come into it?

It's not an entirely unreasable question. memset() lets you
copy a specified 1-byte value repeatedly into a target array.
A generalization of memset() that can copy an N-byte pattern
repeatedly in the same manner could be useful.

But since there is no such function in the standard library, the
best solution is ...

Just use a loop...

static const struct foo foo_zero; /* zero initialised */
for (i = 0; i < N; i++)
array = foo_zero;

Though I'd probably declare foo_zero as:

static const struct foo foo_zero = { 0 };

It's exactly equivalent, but sometimes being a bit more explicit
can be a good thing.

 

[Nick Keighley]

As are these (and are equally relevant):

int three = 3;
assert(threee == 3);

Kenny is (probably on purpose) missing the point.
Although all-bits-zero may not be a null pointer
(and hence the memset() trick won't work)
all the asserts that pete quotes *do* work.

The 0 in the declarations can be thought of
as a null pointer constant. The FAQ discusses
this at length.

<snip rudeness>

Note: Kenny is a troll and shouldn't normally
be responded to.

--
Nick Keighley

I have found that all ugly things are made by those who strive to make
something beautiful and that all beautiful things are made by those
who
strive to make something useful.
-- Oscar Wilde

 

[Kenny McCormack]

As are these (and are equally relevant):

int three = 3;
assert(threee == 3);

Although all-bits-zero may not be a null pointer
(and hence the memset() trick won't work)
all the asserts that pete quotes *do* work.[/QUOTE]

Nobody disputes that. As are all of my asserts. The relevance is all
of equal value.

The 0 in the declarations can be thought of
as a null pointer constant. The FAQ discusses
this at length.

<snip rudeness>

Note: Kenny is a troll and shouldn't normally
be responded to.

The response was normal for you.

 

[viza]

Hi

viza wrote:
Is there then some library function to set an array of objects of
size > 1 to the same value?

Where does the size come into it?

It's not an entirely unreasable question. memset() lets you copy a
specified 1-byte value repeatedly into a target array. A generalization
of memset() that can copy an N-byte pattern repeatedly in the same
manner could be useful. [...]

Here's one I wrote some years ago. It looks at first glance
like it would be murder on cache lines, TLB's, and the like, but in
testing on a few different machine architectures no such bad effects
have appeared.

void
fillmem(void *pdest, size_t sdest, const void *pfrom, size_t sfrom)

/* Copy data from the beginning of the destination to the
* end, with each iteration doubling the amount copied. */

Well that is quite cunning. Not quite the fox appointed as professor of
cunning at oxford, but better than a loop.

If I was going to really squeeze it for every last drop of speed I would
do several loops of copying the system's largest words first, and then
use memcpy as above, once the call overhead was offset. Obviously that
would only be of use on systems where memcpy was faster than a raw loop
anyway.

 

[vippstar]

On 6 Jul, 00:51, (Kenny the Troll)

first is 'three', second is 'threee'.

Note: Kenny is a troll and shouldn't normally
be responded to.

So why did you reply to him?
Please just avoid replying to trolls.

 

[Nick Keighley]

On Jul 7, 12:42 pm,Nick Keighley<[email protected]>


So why did you reply to him?
Please just avoid replying to trolls.

because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

 

[jacob navia]

because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

They are more worth than the posts from heathfield clique.

 

[Keith Thompson]

Nick Keighley wrote: [...]

because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

They are more worth than the posts from heathfield clique.

You can't possibly be serious.

 

[Kenny McCormack]

because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

I doubt even the greenest of newbie would make that mistake.

Pete's stuff is obviously worthless; anyone can see that.

 

[user923005]

Nick Keighley wrote: [...]

because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

They are more worth than the posts from heathfield clique.

You can't possibly be serious.

No, he's just bitter because of his ongoing spat. I'm sure that he
does recognize Richard's ability (which is quite substantial) but his
animosity prevents a sensible reply here.
I guess that you also surmise as much and your answer is really
rhetorical. And while one is not supposed to answer a rhetorical
question, there are plenty of other faux-pas in this thread along the
same lines.

 

[vippstar]

because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

Let it be. If the observer cares to know, he'll read more posts from
both and he'll decide accordingly.

 

[santosh]

Nick Keighley wrote: [...]
because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

They are more worth than the posts from heathfield clique.

You can't possibly be serious.

No, he's just bitter because of his ongoing spat. I'm sure that he
does recognize Richard's ability (which is quite substantial) but his
animosity prevents a sensible reply here.
I guess that you also surmise as much and your answer is really
rhetorical. And while one is not supposed to answer a rhetorical
question, there are plenty of other faux-pas in this thread along the
same lines.

Was what Keith said even a question? Looks more like a statement to
me.