Reinitializing static array???

[Charles Sullivan]

Assume I have a static array of structures the elements of which
could be any conceivable mixture of C types, pointers, arrays.
And this array is uninitialized at program startup.

If later in the program I wish to return this array to its
startup state, can this be accomplished by writing binary
zeroes to the entire memory block with memset(). E.g.,

static struct mystruct_st {
int x1;
int *x2;
double x3[10];
- - -
} myarray[20];

/* Do things with myarray */
- - -
/* Restore initial myarray */
memset(my, 0, sizeof(myarray) );

(where "- - -" indicates other valid code)

Or do the initial values of the elements depend on the
version or implementation of C?

Thanks for your help.

Regards,
Charles Sullivan

[Keith Thompson]

Flash Gordon <sp**@flash-gordon.me.uk> writes:

Keith Thompson wrote:

One good way to get a "zero" value for a structure type is:
struct my_struct {
... member declarations ...
};
struct my_struct my_struct_zero = { 0 };

I would suggest using
const struct my_struct_zero = { 0 };
So the compiler complains about any attempt to modify it otherwise
things very puzzling to another programmer could happen.

Yes, thanks for the improvement.

--
Keith Thompson (The_Other_Keit h) ks***@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.

[those who know me have no need of my name]

in comp.lang.c i read:

Assume I have a static array
[...] uninitialized at program startup.
which is to say implicitly initialized, every member of every element to
the type's zero value, whether that means all bits zero or something else.
If later in the program I wish to return this array to its
startup state, can this be accomplished by writing binary
zeroes to the entire memory block with memset(). E.g.,

not portably.

use a second static object, and memcpy if it's an array. if the array is
large a single element and a loop.

--
a signature

[kar1107]

Eric Sosman wrote:

Charles Sullivan wrote On 10/03/05 13:16,:

Assume I have a static array of structures the elements of which
could be any conceivable mixture of C types, pointers, arrays.
And this array is uninitialized at program startup.

If later in the program I wish to return this array to its
startup state, can this be accomplished by writing binary
zeroes to the entire memory block with memset(). E.g.,

static struct mystruct_st {
int x1;
int *x2;
double x3[10];
- - -
} myarray[20];

/* Do things with myarray */
- - -
/* Restore initial myarray */
memset(my, 0, sizeof(myarray) );

(where "- - -" indicates other valid code)

Or do the initial values of the elements depend on the
version or implementation of C?
A static variable is never "uninitiali zed" in C. It
may lack an explicit initializer, or it may have an
initializer that omits some of its constituent elements,
but if so all those "uninitiali zed" chunks are initialized
to zeroes of appropriate types. That is, each `int' is
initialized to `0', each `unsigned int' to `0u', each
`float' to `0.0f', each pointer to `(WhateverType* )0',
and so on.

But there's a catch: C does not specify very much about
how values are represented. For the various integer types
C promises that filling an appropriately-sized (and -aligned)
region of memory with all-bits-zero produces a zero value.
However, no such guarantee is made for `float', `double',
`long double', or pointer types. It is at least possible
that all-bits-zero is not a valid representation of `0.0f',
`0.0', or `0.0L', and may not be a valid null pointer. On
many machines it happens that these things are in fact
represented as all-bits-zero -- it's so convenient -- but
the language doesn't require it, and there are (or have been)
machines that use(d) other representations .

So: Your memset will certainly work if all the things
being zapped are integers, and will probably (but not
certainly) work if there are non-integer elements involved.
If you decide to use memset() you're running a small risk;
if you'd prefer to avoid the risk, try something like:

void clear_structs(s truct mystruct_st *p, size_t n) {
const struct mystruct_st empty = { 0 };
while (n-- > 0)
*p++ = empty;

why not the much simpler
*p = empty;

And there is no need for the argument 'n'

Am I missing something? BTW {0} syntax in the init may not
work in the first member in mystruct_st itself is a struct.
It may need {{0}} or even {{{0}}} (If that struct also had a struct
as first member)

Karhik

}

--
Er*********@sun .com

[Michael Wojcik]

In article <11************ **********@o13g 2000cwo.googleg roups.com>, "ka*****@gmail. com" <ka*****@gmail. com> writes:

BTW {0} syntax in the init may not
work in the first member in mystruct_st itself is a struct.
It may need {{0}} or even {{{0}}} (If that struct also had a struct
as first member)

No, it need not. {0} is always a valid initializer for an object
of any complete type, or an array of unknown size. (Obviously it's
not valid for objects of incomplete type, namely incomplete structs
and unions and variable-length arrays.)

For scalar objects, {0} follows from ISO 9899-1999 6.7.8 #11. For
aggregate and union objects, {0} follows from the same section, #13,
#16, #17, and #19-#22. See also (non-normative) footnote 127.

Chapter and verse if you believe otherwise, please.

--
Michael Wojcik mi************@ microfocus.com

The lark is exclusively a Soviet bird. The lark does not like the
other countries, and lets its harmonious song be heard only over the
fields made fertile by the collective labor of the citizens of the
happy land of the Soviets. -- D. Bleiman

[kar1107]

Michael Wojcik wrote:

In article <11************ **********@o13g 2000cwo.googleg roups.com>, "ka*****@gmail. com" <ka*****@gmail. com> writes:

BTW {0} syntax in the init may not
work in the first member in mystruct_st itself is a struct.
It may need {{0}} or even {{{0}}} (If that struct also had a struct
as first member)
No, it need not. {0} is always a valid initializer for an object
of any complete type, or an array of unknown size. (Obviously it's
not valid for objects of incomplete type, namely incomplete structs
and unions and variable-length arrays.)

For scalar objects, {0} follows from ISO 9899-1999 6.7.8 #11. For
aggregate and union objects, {0} follows from the same section, #13,
#16, #17, and #19-#22. See also (non-normative) footnote 127.

Chapter and verse if you believe otherwise, please.

You could be right since I have only seen the behavior of gcc
in such a case. As you say, probably it is very valid C. I double
checked, it is just that gcc is emitting different warnings. It does
produce correct runtime behavior though.

$>cat struct_init.c
#include <stdio.h>
#include <stdlib.h>
typedef struct foo_phy_st_ {
int age;
int ht;
int wt;
} foo_phy_st;

typedef struct foo_edu_st_ {
int years;
} foo_edu_st;
typedef struct foo_person_st_ {
foo_phy_st phy;
foo_edu_st edu;
} foo_person_st;


int main (void)
{
#ifdef MULTI_BRACES
foo_person_st a = {{0}};
#else
foo_person_st a = {0};
#endif
printf("%d %d\n", a.phy.age, a.edu.years);
return 0;
}

$> gcc -Wall -W -ansi -pedantic struct_init.c
struct_init.c: In function `main':
struct_init.c:2 5: warning: missing braces around initializer
struct_init.c:2 5: warning: (near initialization for `a.phy')
struct_init.c:2 5: warning: missing initializer
struct_init.c:2 5: warning: (near initialization for `a.phy.ht')
struct_init.c:2 5: warning: missing initializer
struct_init.c:2 5: warning: (near initialization for `a.edu')
$> gcc -Wall -W -ansi -pedantic -DMULTI_BRACES struct_init.c
struct_init.c: In function `main':
struct_init.c:2 3: warning: missing initializer
struct_init.c:2 3: warning: (near initialization for `a.phy.ht')
struct_init.c:2 3: warning: missing initializer
struct_init.c:2 3: warning: (near initialization for `a.edu')
$> gcc -ansi -pedantic struct_init.c
struct_init.c: In function `main':
struct_init.c:2 5: warning: missing braces around initializer
struct_init.c:2 5: warning: (near initialization for `a.phy')
struct_init.c:2 5: warning: missing initializer
struct_init.c:2 5: warning: (near initialization for `a.phy.ht')
struct_init.c:2 5: warning: missing initializer
struct_init.c:2 5: warning: (near initialization for `a.edu')
$> gcc struct_init.c
struct_init.c: In function `main':
struct_init.c:2 5: warning: missing braces around initializer
struct_init.c:2 5: warning: (near initialization for `a.phy')
struct_init.c:2 5: warning: missing initializer
struct_init.c:2 5: warning: (near initialization for `a.phy.ht')
struct_init.c:2 5: warning: missing initializer
struct_init.c:2 5: warning: (near initialization for `a.edu')

$> gcc -Wall -W -ansi -std=c99 -pedantic struct_init.c
struct_init.c: In function `main':
struct_init.c:2 5: warning: missing braces around initializer
struct_init.c:2 5: warning: (near initialization for `a.phy')
struct_init.c:2 5: warning: missing initializer
struct_init.c:2 5: warning: (near initialization for `a.phy.ht')
struct_init.c:2 5: warning: missing initializer
struct_init.c:2 5: warning: (near initialization for `a.edu')

$> gcc --version
gcc (GCC) 3.3.3 (Yellow Dog Linux 3.3.3-16.ydl.8)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Karthik
--
Michael Wojcik mi************@ microfocus.com

The lark is exclusively a Soviet bird. The lark does not like the
other countries, and lets its harmonious song be heard only over the
fields made fertile by the collective labor of the citizens of the
happy land of the Soviets. -- D. Bleiman

[Michael Wojcik]

In article <11************ *********@g43g2 000cwa.googlegr oups.com>, "ka*****@gmail. com" <ka*****@gmail. com> writes:

Michael Wojcik wrote:

In article <11************ **********@o13g 2000cwo.googleg roups.com>, "ka*****@gmail. com" <ka*****@gmail. com> writes:

BTW {0} syntax in the init may not
work in the first member in mystruct_st itself is a struct.
It may need {{0}} or even {{{0}}} (If that struct also had a struct
as first member)

No, it need not. {0} is always a valid initializer for an object
of any complete type, or an array of unknown size.

You could be right since I have only seen the behavior of gcc
in such a case. As you say, probably it is very valid C. I double
checked, it is just that gcc is emitting different warnings.

The behavior of an implementation - even the behavior of *all*
implementations - does not define the language; the standard does.
Obviously, if commonly-used implementations deviate from the standard
in some way (which is not the case with gcc here; I'm just hypothe-
sizing), it may be practical to write for them rather than for the
language as it's actually defined. However, it's usually unwise to
make claims here that are backed up only by experimenting with a
single implementation. If you wish to do so anyway, I recommend
qualifying them ("With gcc, ...").

Of course an implementation can emit whatever diagnostics it likes,
even if it's complaining about a perfectly valid and useful
construct.

[OT] Splint also complains about {0} as an initializer in some
cases, such as when initializing an array of struct. Very annoying;
it's on my list of misfeatures to fix. (I am, on the whole, not
very fond of Splint, but it's one of the better choices among the
free tools. I may yet seek budget for switching my group to a
commercial tool for C static defect analysis, though.)

--
Michael Wojcik mi************@ microfocus.com

Push up the bottom with your finger, it will puffy and makes stand up.
-- instructions for "swan" from an origami kit