«

On Wed, 31 Aug 2005 10:04:29 -0700, Tim Rentsch wrote:

> Barry Schwarz <> writes:
>
>> Thirdly, pointer to void is "compatible" with any other unqualified
>> object pointer type. This means that the compiler can implicitly
>> convert one to the other whenever it needs to without requiring a
>> cast.
>
> Just a minor correction. The word "compatible" is
> used in the standard document following a particular
> definition (section 6.2.7 p1, and others).
>
> In the sense of this definition, void pointers and
> non-void pointers are not "compatible". They can be
> used interchangeably in many contexts, but they are
> not "compatible" in the sense that the standard
> document uses the word.

Perhaps the term "assignment compatible" is appropriate here. While not
strictly a standard term its meaning is clear.

Lawrence

"Peter Nilsson" <> wrote in message
news: ups.com...
> srivatsan_b wrote:
> > Hi,
> >
> > Can somebody explain whether an explicit typecast is mandatory while
> > calling memset function for a structure? like in the following code
> > snapshot.....
> > struct some_structure x;
> > memset((some_structure*)&x,0,sizeof(some_structure ));
> > Will memset(&x,0,sizeof(some_structure)); cause some issues?
>
> Slightly better is... memset(&x, 0, sizeof x);
....
> Where you may have problems is that setting all the bits of the
> structure contents to zero, may not do what you want. If your
> structure contains pointers for instance, then setting the bits to
> 0 need not set them to null pointers.

While this is true in theory from the words of the holy C99 norm, can you name
actual contemporary architectures where this is true in practice? What about
integral and floating point types? Any example of machines on which clearing
them to all bits zero is not advisable or does not produce 0 values?

DS9000 will not be accepted as an answer.

> If you want to zero initialise a structure (or indeed any other
> object type), then you simply need to do...
>
> struct some_structure x = { 0 };
>
> No memset is required.

how can you re-initialize it after use ?

Chqrlie.

* Charlie Gordon:
> >
> > struct some_structure x = { 0 };
> >
> > No memset is required.
>
> how can you re-initialize it after use ?

static SomeStructure const someStructure0 = {};

SomeStructure x = {};
....
x = someStructure0;


Not that that it's generally a good idea to "re-initialize". Because that
implies a variable used for two or more different things. If such things
are systematically removed, the code generally becomes a lot cleaner.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

"Alf P. Steinbach" <> wrote in message
news:...
> * Charlie Gordon:
> > >
> > > struct some_structure x = { 0 };
> > >
> > > No memset is required.
> >
> > how can you re-initialize it after use ?
>
> static SomeStructure const someStructure0 = {};

Can you omit the ={} initializer if this one is at file scope?

> SomeStructure x = {};
> ...
> x = someStructure0;

what about not using an explicit static variable.
can't you do this with an unnamed structure in C99?

> Not that that it's generally a good idea to "re-initialize". Because that
> implies a variable used for two or more different things. If such things
> are systematically removed, the code generally becomes a lot cleaner.

I agree, but this structure might be part of a larger one.

Chqrlie.

On 31 Aug 2005 11:36:14 -0700, Tim Rentsch <>
wrote in comp.lang.c:

> Lawrence Kirby <> writes:
>
> > On Wed, 31 Aug 2005 10:04:29 -0700, Tim Rentsch wrote:
> >
> > > Barry Schwarz <> writes:
> > >
> > >> Thirdly, pointer to void is "compatible" with any other unqualified
> > >> object pointer type. This means that the compiler can implicitly
> > >> convert one to the other whenever it needs to without requiring a
> > >> cast.
> > >
> > > Just a minor correction. The word "compatible" is
> > > used in the standard document following a particular
> > > definition (section 6.2.7 p1, and others).
> > >
> > > In the sense of this definition, void pointers and
> > > non-void pointers are not "compatible". They can be
> > > used interchangeably in many contexts, but they are
> > > not "compatible" in the sense that the standard
> > > document uses the word.
> >
> > Perhaps the term "assignment compatible" is appropriate here. While not
> > strictly a standard term its meaning is clear.
>
> I propose "implicitly convertible". It's descriptive,
> and accurate.
>
> Besides the confusion around "compatible", the term
> "assignment compatible" suggests that the conversion
> happens only for assignment (or function arguments);
> whereas void pointers can also be used with non-void
> pointers in other contexts, eg, equality comparisons,
> or as one side of a ?: result set.

What do you mean by equality comparisons? Are you implying code like
this:

#include <stdio.h>

int main(void)
{
int x = 0;
int *ip = &x;
void *vp = &x;
if (vp == ip)
puts("they match");
else
puts("they don't");
return x;
}

....is valid?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Jack Klein <> writes:
> On 31 Aug 2005 11:36:14 -0700, Tim Rentsch <>
> wrote in comp.lang.c:
[...]
>> I propose "implicitly convertible". It's descriptive,
>> and accurate.
>>
>> Besides the confusion around "compatible", the term
>> "assignment compatible" suggests that the conversion
>> happens only for assignment (or function arguments);
>> whereas void pointers can also be used with non-void
>> pointers in other contexts, eg, equality comparisons,
>> or as one side of a ?: result set.
>
> What do you mean by equality comparisons? Are you implying code like
> this:
>
> #include <stdio.h>
>
> int main(void)
> {
> int x = 0;
> int *ip = &x;
> void *vp = &x;
> if (vp == ip)
> puts("they match");
> else
> puts("they don't");
> return x;
> }
>
> ...is valid?

I believe it is. Are you implying that it isn't?

C99 6.5.9 Equality operators:

Constraints

One of the following shall hold:

-- both operands have arithmetic type;

-- both operands are pointers to qualified or unqualified versions
of compatible types;

-- one operand is a pointer to an object or incomplete type and
the other is a pointer to a qualified or unqualified version of
void; or

-- one operand is a pointer and the other is a null pointer constant.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Jack Klein <> writes:

> On 31 Aug 2005 11:36:14 -0700, Tim Rentsch <>
> wrote in comp.lang.c:
>
> > Lawrence Kirby <> writes:
> >
> > > On Wed, 31 Aug 2005 10:04:29 -0700, Tim Rentsch wrote:
> > >
> > > > Barry Schwarz <> writes:
> > > >
> > > >> Thirdly, pointer to void is "compatible" with any other unqualified
> > > >> object pointer type. This means that the compiler can implicitly
> > > >> convert one to the other whenever it needs to without requiring a
> > > >> cast.
> > > >
> > > > Just a minor correction. The word "compatible" is
> > > > used in the standard document following a particular
> > > > definition (section 6.2.7 p1, and others).
> > > >
> > > > In the sense of this definition, void pointers and
> > > > non-void pointers are not "compatible". They can be
> > > > used interchangeably in many contexts, but they are
> > > > not "compatible" in the sense that the standard
> > > > document uses the word.
> > >
> > > Perhaps the term "assignment compatible" is appropriate here. While not
> > > strictly a standard term its meaning is clear.
> >
> > I propose "implicitly convertible". It's descriptive,
> > and accurate.
> >
> > Besides the confusion around "compatible", the term
> > "assignment compatible" suggests that the conversion
> > happens only for assignment (or function arguments);
> > whereas void pointers can also be used with non-void
> > pointers in other contexts, eg, equality comparisons,
> > or as one side of a ?: result set.
>
> What do you mean by equality comparisons? Are you implying code like
> this:
>
> #include <stdio.h>
>
> int main(void)
> {
> int x = 0;
> int *ip = &x;
> void *vp = &x;
> if (vp == ip)
> puts("they match");
> else
> puts("they don't");
> return x;
> }
>
> ...is valid?

Yes. Did you try it? Keith Thompson quoted the relevant
section, 6.5.9, at least the Constraints part of it, in his
posting. (Thanks Keith.)

Charlie Gordon <> wrote:
> "Alf P. Steinbach" <> wrote in message
> news:...
> > * Charlie Gordon:
> > > >
> > > > struct some_structure x = { 0 };
> > > >
> > > > No memset is required.
> > >
> > > how can you re-initialize it after use ?
> >
> > static SomeStructure const someStructure0 = {};

> Can you omit the ={} initializer if this one is at file scope?

Of course. But, sometime's I'll include the braces as a stub. Often times I
need to go back and initialize some member(s) of the initializer with
non-zero values.

> > SomeStructure x = {};
> > ...
> > x = someStructure0;

> what about not using an explicit static variable.
> can't you do this with an unnamed structure in C99?

yep

x = (SomeStructure){ 0 };

"William Ahern" <> wrote in message
news:49miu2-...
> Charlie Gordon <> wrote:
> > "Alf P. Steinbach" <> wrote in message
> > news:...
> > > * Charlie Gordon:
> > > > >
> > > > > struct some_structure x = { 0 };
> > > > >
> > > > > No memset is required.
> > > >
> > > > how can you re-initialize it after use ?
> > >
> > > static SomeStructure const someStructure0 = {};
>
> > Can you omit the ={} initializer if this one is at file scope?
>
> Of course. But, sometime's I'll include the braces as a stub. Often times I
> need to go back and initialize some member(s) of the initializer with
> non-zero values.
>
> > > SomeStructure x = {};
> > > ...
> > > x = someStructure0;
>
> > what about not using an explicit static variable.
> > can't you do this with an unnamed structure in C99?
>
> yep
>
> x = (SomeStructure){ 0 };

Is the 0 necessary in this case ?

Chqrlie.

Default User <> schrieb:

<nitpick>

> No. There is no implicit conversion FROM void*. So malloc() needs a
> cast, memset() doesn't.

No, you can assign a void* to any type of pointer-variable. You only
need to cast malloc() when using C++.

</nitpick>

Markus