memset doubt

[srivatsan_b]

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_st ructure*)&x,0,s izeof(some_stru cture));
Will memset(&x,0,siz eof(some_struct ure)); cause some issues?

Thanks in advance
Srivatsan

[Peter Nilsson]

Re: memset doubt

srivatsan_b wrote:[color=blue]
> 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_st ructure*)&x,0,s izeof(some_stru cture));
> Will memset(&x,0,siz eof(some_struct ure)); cause some issues?[/color]

Slightly better is... memset(&x, 0, sizeof x);

In C, there is an issue, but it's not the issue you're asking about.

In C, any object pointer can be implicitly converted to a pointer
to void [subject to cv-qualifiers.] So the answer to your question
is no. C++ is different, but you should ask in a C++ group if you
ere actually using a C++ compiler.

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.

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.

--
Peter

[Keith Thompson]

Re: memset doubt

"srivatsan_ b" <srivatsanbs@gm ail.com> writes:[color=blue]
> 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_st ructure*)&x,0,s izeof(some_stru cture));
> Will memset(&x,0,siz eof(some_struct ure)); cause some issues?[/color]

Assuming that you've remembered to #include <string.h>, which declares
the memset() function, the cast is unnecessary. Any object pointer
type can be implicitly converted to void*, and vice versa.

There are a couple of problems with your code, one serious and one
cosmetic.

Given a declaration of "struct some_structure" , there is no type
called "some_structure "; the struct keyword is necessary unless you've
also declared it as a typedef. (Some would argue that typedefs for
struct types are poor style.)

<OT>
Note that the rules are different for C++. If I recall correctly, a
declaration of "struct some_structure" makes "some_structure " visible
as a type name, and there is no implicit conversion to void*. That
shouldn't be relevant unless you're using a C++ compiler -- and if you
are, you're in the wrong newsgroup.
</OT>

Also, using the size of the object makes for cleaner code than using
the size of the type. For example:

struct some_structure x;
memset(&x, 0, sizeof x);

Not only is this shorter, it avoid errors if the type of x is changed.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <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.

[Barry Schwarz]

Re: memset doubt

On 30 Aug 2005 22:43:54 -0700, "srivatsan_ b" <srivatsanbs@gm ail.com>
wrote:
[color=blue]
>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_st ructure*)&x,0,s izeof(some_stru cture));
>Will memset(&x,0,siz eof(some_struct ure)); cause some issues?
>[/color]

Firstly, &x already has type pointer to struct some_structure.
Therefore, casting any value to the same type it already has is by
definition redundant.

Secondly, memset expects the first argument to have type pointer to
void. If you were going to cast the value, that is what you would
cast it to.

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.

The only problem with your final question is that for C89 compilers
the cast must include the keyword struct. The use of the structure
tag without the keyword did not become standard until C99 and there
are very few compilers of that grade in use.


<<Remove the del for email>>

[Keith Thompson]

Re: memset doubt

Barry Schwarz <schwarzb@deloz .net> writes:[color=blue]
> On 30 Aug 2005 22:43:54 -0700, "srivatsan_ b" <srivatsanbs@gm ail.com>
> wrote:[/color]
[...][color=blue]
> The only problem with your final question is that for C89 compilers
> the cast must include the keyword struct. The use of the structure
> tag without the keyword did not become standard until C99 and there
> are very few compilers of that grade in use.[/color]

No, a declaration of "struct foo" doesn't make just "foo" visible as a
type name in either C89 or C99. (It does in C++.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <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.

[Emmanuel Delahaye]

Re: memset doubt

srivatsan_b wrote on 31/08/05 :[color=blue]
> Can somebody explain whether an explicit typecast is mandatory while[/color]

It's not. Be sure that <string.h> is in scope and that you are using a
C compiler...
[color=blue]
> calling memset function for a structure? like in the following code
> snapshot.....
> struct some_structure x;
> memset((some_st ructure*)&x,0,s izeof(some_stru cture));[/color]

Plain wrong. You meant:

struct some_structure x;
memset((struct some_structure* )&x,0, sizeof(struct some_structure) );
[color=blue]
> Will memset(&x,0,siz eof(some_struct ure)); cause some issues?[/color]

No, as long as 'x' has the type 'some_structure '. This is why I prefer
to use the size of the the object itself.

memset (&x, 0, sizeof x);

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.

[Tim Rentsch]

Re: memset doubt

Barry Schwarz <schwarzb@deloz .net> writes:
[color=blue]
> 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.[/color]

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.

[Default User]

Re: memset doubt

Peter Nilsson wrote:

[color=blue]
> In C, any object pointer can be implicitly converted to a pointer
> to void [subject to cv-qualifiers.] So the answer to your question
> is no. C++ is different, but you should ask in a C++ group if you
> ere actually using a C++ compiler.[/color]

C++ is not different in this case. The difference is that void* can't
be converted to an object pointer without a cast.



Brian

[Default User]

Re: memset doubt

Keith Thompson wrote:

[color=blue]
> <OT>
> Note that the rules are different for C++. If I recall correctly, a
> declaration of "struct some_structure" makes "some_structure " visible
> as a type name,[/color]

Yes.
[color=blue]
> and there is no implicit conversion to void*.[/color]

No. There is no implicit conversion FROM void*. So malloc() needs a
cast, memset() doesn't.
[color=blue]
> </OT>[/color]

[Lawrence Kirby]

Re: memset doubt

On Wed, 31 Aug 2005 10:04:29 -0700, Tim Rentsch wrote:
[color=blue]
> Barry Schwarz <schwarzb@deloz .net> writes:
>[color=green]
>> 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.[/color]
>
> 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.[/color]

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

Lawrence

[Tim Rentsch]

Re: memset doubt

Lawrence Kirby <lknews@netacti ve.co.uk> writes:
[color=blue]
> On Wed, 31 Aug 2005 10:04:29 -0700, Tim Rentsch wrote:
>[color=green]
> > Barry Schwarz <schwarzb@deloz .net> writes:
> >[color=darkred]
> >> 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.[/color]
> >
> > 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.[/color]
>
> Perhaps the term "assignment compatible" is appropriate here. While not
> strictly a standard term its meaning is clear.[/color]

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.

[Charlie Gordon]

Re: memset doubt

"Peter Nilsson" <airia@acay.com .au> wrote in message
news:1125467988 .701809.68890@g 47g2000cwa.goog legroups.com...[color=blue]
> srivatsan_b wrote:[color=green]
> > 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_st ructure*)&x,0,s izeof(some_stru cture));
> > Will memset(&x,0,siz eof(some_struct ure)); cause some issues?[/color]
>
> Slightly better is... memset(&x, 0, sizeof x);[/color]
....[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

how can you re-initialize it after use ?

Chqrlie.

[Alf P. Steinbach]

Re: memset doubt

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

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?

[Charlie Gordon]

Re: memset doubt

"Alf P. Steinbach" <alfps@start.no > wrote in message
news:431623e8.1 641758265@news. individual.net. ..[color=blue]
> * Charlie Gordon:[color=green][color=darkred]
> > >
> > > struct some_structure x = { 0 };
> > >
> > > No memset is required.[/color]
> >
> > how can you re-initialize it after use ?[/color]
>
> static SomeStructure const someStructure0 = {};[/color]

Can you omit the ={} initializer if this one is at file scope?
[color=blue]
> SomeStructure x = {};
> ...
> x = someStructure0;[/color]

what about not using an explicit static variable.
can't you do this with an unnamed structure in C99?
[color=blue]
> 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.[/color]

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

Chqrlie.

[Jack Klein]

Re: memset doubt

On 31 Aug 2005 11:36:14 -0700, Tim Rentsch <txr@alumnus.ca ltech.edu>
wrote in comp.lang.c:
[color=blue]
> Lawrence Kirby <lknews@netacti ve.co.uk> writes:
>[color=green]
> > On Wed, 31 Aug 2005 10:04:29 -0700, Tim Rentsch wrote:
> >[color=darkred]
> > > Barry Schwarz <schwarzb@deloz .net> 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.[/color]
> >
> > Perhaps the term "assignment compatible" is appropriate here. While not
> > strictly a standard term its meaning is clear.[/color]
>
> 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.[/color]

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.l earn.c-c++

http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html