curious about array initialization.

[questions?]

say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

if the array is not intialized by me, in a sense after I allocated a
memory for the structure, will the integer array be initialized to 0
for all entries? (e.g. month[0]-month[11] are all equal 0).

Is this compiler dependent or random?

Thanks

 

[Andrew Poelstra]

say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

if the array is not intialized by me, in a sense after I allocated a
memory for the structure, will the integer array be initialized to 0
for all entries? (e.g. month[0]-month[11] are all equal 0).

Is this compiler dependent or random?

Thanks

I would imagine that it would be compiler-dependant, but I don't know
the Standard nearly as well as a lot of people here.

You can't assume that your arrays will be initialized to 0, so the
specific reason that you can't is for the most part irrelevant.

 

[Keith Thompson]

say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

if the array is not intialized by me, in a sense after I allocated a
memory for the structure, will the integer array be initialized to 0
for all entries? (e.g. month[0]-month[11] are all equal 0).

If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type). If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.

 

[bobrics]

say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

if the array is not intialized by me, in a sense after I allocated a
memory for the structure, will the integer array be initialized to 0
for all entries? (e.g. month[0]-month[11] are all equal 0).

If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type). If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.

What do you mean by static storage duration? Are you referring to array
declaration as the one given above?

Also, I have tried to run the code in DevC++ 4.9.9.2:
#include <stdio.h>

int main() {
int i;

struct random_struct{
char name[10];
int month[12];

} mystruct;

for (i=0; i<10; i++) {
printf("%d\t%c\n", mystruct.month, mystruct.name);
}

getchar();

return 0;
}
---------------------------------

Here is the output. Neither the integer array, nor char were
initialized to 0. You cannot assume that. So just preinitialize
everything that you are using to avoid any problems. Check out
memset(). I think memset(&mystruct, 0, sizeof(mystruct)); should do the
job for the whole structure at once, but double check that.

-1 `
2009252814 #
2293528 $
8
2293728 ö
2009291924 \
2009145456 +
-1 w
2009252579 ê
2009315348

Regards

 

[pete]

say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0',
or NULL depending on
the type).
If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.

What do you mean by static storage duration?

He definitely means something.

Are you referring to array
declaration as the one given above?

Can't tell, without seeing the object definition.

Also, I have tried to run the code in DevC++ 4.9.9.2:
#include <stdio.h>

int main() {
int i;

struct random_struct{
char name[10];
int month[12];

} mystruct;

for (i=0; i<10; i++) {
printf("%d\t%c\n", mystruct.month, mystruct.name);
}

getchar();

return 0;
}

Try new.c instead.

Here is the output.

0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0

The integer array, and char were initialized to 0.
You can assume that, for external object definitions,
because they have static duration.

/* BEGIN new.c */

#include <stdio.h>

struct random_struct {
char name[10];
int month[12];
} mystruct;

int main(void)
{
int i;

for (i=0; i<10; i++) {
printf("%d\t%c\n", mystruct.month, '0' + mystruct.name);
}
return 0;
}

/* END new.c */

 

[Keith Thompson]

say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

if the array is not intialized by me, in a sense after I allocated a
memory for the structure, will the integer array be initialized to 0
for all entries? (e.g. month[0]-month[11] are all equal 0).

If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type). If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.

What do you mean by static storage duration? Are you referring to array
declaration as the one given above?

No, the declaration above declares a type, not an object, so it has no
storage duration.

An object with static storage duration lives until the program
finishes. An object with automatic storage duration ceases to exist
at the end of the block or function in which it's declared.

An object declared outside any function has static storage duration.
An object declared inside a function has automatic storage duration
unless it's declared with the keyword "static".

The reason only objects with static storage duration are initialized
to zero is basically implementation convenience. On many (most?)
implementations, objects with static storage duration are allocated in
a contiguous block that's zeroed all at once when the program is first
loaded. For automatic objects to be initialized to zero, the compiler
would have to generate additional initialization code that's executed
whenever the scope (e.g., the containing function) is entered.

Also, I have tried to run the code in DevC++ 4.9.9.2:
#include <stdio.h>

int main() {
int i;

struct random_struct{
char name[10];
int month[12];

} mystruct;

mystruct has automatic storage duration, so it's not initialized.

for (i=0; i<10; i++) {
printf("%d\t%c\n", mystruct.month, mystruct.name);
}

getchar();

return 0;
}

[...]

If you want to initialize it to zero, you can always do so explicitly:

struct random_struct{
char name[10];
int month[12];
} mystruct = { 0 };

-
Keith Thompson (The_Other_Keith) (e-mail address removed) <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.

 

[questions?]

say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

if the array is not intialized by me, in a sense after I allocated a
memory for the structure, will the integer array be initialized to 0
for all entries? (e.g. month[0]-month[11] are all equal 0).

If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type). If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.

What do you mean by static storage duration? Are you referring to array
declaration as the one given above?

No, the declaration above declares a type, not an object, so it has no
storage duration.

An object with static storage duration lives until the program
finishes. An object with automatic storage duration ceases to exist
at the end of the block or function in which it's declared.

An object declared outside any function has static storage duration.
An object declared inside a function has automatic storage duration
unless it's declared with the keyword "static".

The reason only objects with static storage duration are initialized
to zero is basically implementation convenience. On many (most?)
implementations, objects with static storage duration are allocated in
a contiguous block that's zeroed all at once when the program is first
loaded. For automatic objects to be initialized to zero, the compiler
would have to generate additional initialization code that's executed
whenever the scope (e.g., the containing function) is entered.

Also, I have tried to run the code in DevC++ 4.9.9.2:
#include <stdio.h>

int main() {
int i;

struct random_struct{
char name[10];
int month[12];

} mystruct;

mystruct has automatic storage duration, so it's not initialized.

for (i=0; i<10; i++) {
printf("%d\t%c\n", mystruct.month, mystruct.name);
}

getchar();

return 0;
}

[...]

If you want to initialize it to zero, you can always do so explicitly:

struct random_struct{
char name[10];
int month[12];
} mystruct = { 0 };

-
Keith Thompson (The_Other_Keith) (e-mail address removed) <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.

Thanks for the nice explanation. Cool!

 

[pete]

Keith Thompson wrote:

If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type).

I think of {0} as being the universal default initializer
for static objects.

 

[websnarf]

say I have a structure which have an array inside.

e.g.

struct random_struct{
char name[10];
int month[12];
}

if the array is not intialized by me, in a sense after I allocated a
memory for the structure, will the integer array be initialized to 0
for all entries? (e.g. month[0]-month[11] are all equal 0).

If the object is declared with static storage duration, all members
will be initialized to zero (either 0, 0.0, '\0', or NULL depending on
the type). If it has automatic storage duration, or if it's allocated
with malloc(), the initial value will be garbage -- which might just
happen to be zero.

What do you mean by static storage duration? Are you referring to array
declaration as the one given above?

No, the declaration above declares a type, not an object, so it has no
storage duration.

An object with static storage duration lives until the program
finishes.

Since main is not recursively callable, the compiler is allowed to
allocate its autos "as if" they were static, thus making them have
program lifetime. (This might be useful if the call stack space is
more precious than your data segment in your environment.) Or
alternatively, one can argue that the program lifetime is always under
the scope of main, meaning that its autos have duration of the whole
program.

I would instead say, that a static *variable* is something either with
file scope (declared outside of any function) or an auto with a static
declaration. General static objects also include initialization values
with implicit storage (such as inline strings, and potential structs,
or unions that contain them, initialized to something other than an
array) and clearly have a value that is self declared rather than being
0.

 

[Richard Bos]

Since main is not recursively callable,

Says who?

comp.lang.c++ is over there -->

Richard

 

[CBFalconer]

Keith Thompson wrote:
.... snip ...

Since main is not recursively callable, the compiler is allowed to
allocate its autos "as if" they were static, thus making them have
program lifetime. (This might be useful if the call stack space
is more precious than your data segment in your environment.) Or
alternatively, one can argue that the program lifetime is always
under the scope of main, meaning that its autos have duration of
the whole program.

Very sloppy, and highly inaccurate. main IS recursively callable.
It cannot in general allocate automatic storage as if static.

#include <stdio.h>

int main(int argc, char **argv) {

if (argc > 1) {
puts(argv[--argc]);
main(argc, argv);
}
return 0;
}

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Keith Thompson]

Keith Thompson wrote: [...]

An object with static storage duration lives until the program
finishes.

Since main is not recursively callable, the compiler is allowed to
allocate its autos "as if" they were static, thus making them have
program lifetime. (This might be useful if the call stack space is
more precious than your data segment in your environment.) Or
alternatively, one can argue that the program lifetime is always under
the scope of main, meaning that its autos have duration of the whole
program.

main is recursively callable.

I would instead say, that a static *variable* is something either with
file scope (declared outside of any function) or an auto with a static
declaration. General static objects also include initialization values
with implicit storage (such as inline strings, and potential structs,
or unions that contain them, initialized to something other than an
array) and clearly have a value that is self declared rather than being
0.

I'm not sure this distinction between objects and "variables" is
useful. The standard carefully avoids defining what a "variable" is
(though it uses the word informally a few times).

 

[Ben Pfaff]

Since main is not recursively callable,

I think you are confusing C with C++. main() may not be called
recursively in C++, but it may in C.

 

[websnarf]

Keith Thompson wrote: [...]

An object with static storage duration lives until the program
finishes.

Since main is not recursively callable, the compiler is allowed to
allocate its autos "as if" they were static, thus making them have
program lifetime. (This might be useful if the call stack space is
more precious than your data segment in your environment.) Or
alternatively, one can argue that the program lifetime is always under
the scope of main, meaning that its autos have duration of the whole
program.

main is recursively callable.

Hmmm ... so it is. I didn't realize this was a C++ only thing. I don't
quite get why there would be a difference between the two languages on
this.

I'm not sure this distinction between objects and "variables" is
useful. The standard carefully avoids defining what a "variable" is
(though it uses the word informally a few times).

Yeah, well the "standard" is not something from which you can derive
any true understanding of anything.

The fact that certain hunks of data can exist should be a seperate
concept to a variable it happens to be sitting in. A *variable* can
cause a hunk of data to inherit const semantics at run time while a
hunk of data intrinsically in of itsef cannot change its const
semantics. So this distinction kind of matters, and it means knowing
the difference between variables, and "objects" is a prerequisite for
"getting" this.

So for example, if you have an inline string, can you return it from a
function? It depends on the attributes of the *variable* it was first
bound to. It can be returned if it was stuck in a char *, but *not* if
it is stuck in a char[]. How does one think about this without
understanding that its through the variable declaration that we
determine this?

 

[Keith Thompson]

(e-mail address removed) writes: [...]

I would instead say, that a static *variable* is something either with
file scope (declared outside of any function) or an auto with a static
declaration. General static objects also include initialization values
with implicit storage (such as inline strings, and potential structs,
or unions that contain them, initialized to something other than an
array) and clearly have a value that is self declared rather than being
0.

I'm not sure this distinction between objects and "variables" is
useful. The standard carefully avoids defining what a "variable" is
(though it uses the word informally a few times).

Yeah, well the "standard" is not something from which you can derive
any true understanding of anything.

I certainly can. I don't know what your problem is.

The fact that certain hunks of data can exist should be a seperate
concept to a variable it happens to be sitting in. A *variable* can
cause a hunk of data to inherit const semantics at run time while a
hunk of data intrinsically in of itsef cannot change its const
semantics. So this distinction kind of matters, and it means knowing
the difference between variables, and "objects" is a prerequisite for
"getting" this.

So for example, if you have an inline string, can you return it from a
function? It depends on the attributes of the *variable* it was first
bound to. It can be returned if it was stuck in a char *, but *not* if
it is stuck in a char[]. How does one think about this without
understanding that its through the variable declaration that we
determine this?

By understanding the attributes of the objects that the program is
operating on.

By "inline string", I assume you mean a string literal. A string
literal corresponds to a static object with certain attributes as
defined in the standard. If it's "stuck in a char*", then you have an
object of type char* that points to the object. If it's "stuck in a
char[]", then you've copied the value of that object to another
object. If that object has automatic storage duration, then returning
a pointer to that object outside the object's scope can cause
undefined behavior; the origin of the value stored in that object is
no longer relevant.

This is all stuff that I learned from the standard.

I don't know what you mean by "variable", other than that it's
apparently something distinct from an object. If you can provide a
rigorous definition of the word "variable", perhaps we can discuss
this.

 

[Typhonike]

c compiler does NOT initialize the variables.when a variable alloceted
in memory it takes random values.

 

[Keith Thompson]

c compiler does NOT initialize the variables.when a variable alloceted
in memory it takes random values.

Incorrect, incomplete, and lacking context.

Read <http://cfaj.freeshell.org/google/>.

The correct answer has already been given in this thread.

 

[Default User]

c compiler does NOT initialize the variables.when a variable alloceted
in memory it takes random values.

Please review the information below.



Brian

 

[websnarf]

(e-mail address removed) writes: [...]
I would instead say, that a static *variable* is something either with
file scope (declared outside of any function) or an auto with a static
declaration. General static objects also include initialization values
with implicit storage (such as inline strings, and potential structs,
or unions that contain them, initialized to something other than an
array) and clearly have a value that is self declared rather than being
0.

I'm not sure this distinction between objects and "variables" is
useful. The standard carefully avoids defining what a "variable" is
(though it uses the word informally a few times).

Yeah, well the "standard" is not something from which you can derive
any true understanding of anything.

I certainly can. I don't know what your problem is.

That's like saying spelling bee champions are expert linguists. A
language standard that goes out of its way to avoid the word variable
seems to me like it maybe has been built on questionable premises.

The fact that certain hunks of data can exist should be a seperate
concept to a variable it happens to be sitting in. A *variable* can
cause a hunk of data to inherit const semantics at run time while a
hunk of data intrinsically in of itsef cannot change its const
semantics. So this distinction kind of matters, and it means knowing
the difference between variables, and "objects" is a prerequisite for
"getting" this.

So for example, if you have an inline string, can you return it from a
function? It depends on the attributes of the *variable* it was first
bound to. It can be returned if it was stuck in a char *, but *not* if
it is stuck in a char[]. How does one think about this without
understanding that its through the variable declaration that we
determine this?

By understanding the attributes of the objects that the program is
operating on.

By "inline string", I assume you mean a string literal. A string
literal corresponds to a static object with certain attributes as
defined in the standard. If it's "stuck in a char*", then you have an
object of type char* that points to the object.

Well, more than that you have implicit storage. The inline string has
to actually exist as a wad of data somewhere.

[...] If it's "stuck in a
char[]", then you've copied the value of that object to another
object.

No, that's a matter of implementation.

char x[] = "xxxx";

is the same as

char x[];
memset (x, 'x', 4);
x[4] = '\0';

and a compiler might easily do that, without the requirement of the
existence of any "xxxx" "object" (actually, this is more likely with
char x[]="", for obvious reaons). Similarly, if you mismatch the size
of the array declaration with the inline string, the compiler has a
bunch of choices as to how to deal with the truncation or expansion of
the array, including the mutation of the representation of the inline
string where it is stored. Since there is no reference to the original
inline string, it does not actually have to exist, or have any property
you think it might have. There's no way for you to force the string
literal to have any particular manifestation you want it to outside of
a particular implementation.

The variable x on the other hand has all sorts of properties. Note
here that in both cases, the variable declaration tells us what the
nature of the string literal's manifestation is, not the string itself.
Understanding comes from knowing what is going on with the variable,
not the string literal.

[...] If that object has automatic storage duration, then returning
a pointer to that object outside the object's scope can cause
undefined behavior; the origin of the value stored in that object is
no longer relevant.

This is all stuff that I learned from the standard.

Yes, but there is the question of what you didn't learn.

I don't know what you mean by "variable",

Its a concept from computer programming. If you are not familliar with
computer programming, you may not have heard of it, but you can't call
yourself a computer programmer, if you don't know what a variable is.

[...] other than that it's
apparently something distinct from an object. If you can provide a
rigorous definition of the word "variable", perhaps we can discuss
this.

Independent named storage? In C I guess it would be declared
independent named storage.

 

[Keith Thompson]

Keith Thompson wrote:
(e-mail address removed) writes: [...]
I would instead say, that a static *variable* is something either with
file scope (declared outside of any function) or an auto with a static
declaration. General static objects also include initialization values
with implicit storage (such as inline strings, and potential structs,
or unions that contain them, initialized to something other than an
array) and clearly have a value that is self declared rather than being
0.

I'm not sure this distinction between objects and "variables" is
useful. The standard carefully avoids defining what a "variable" is
(though it uses the word informally a few times).

Yeah, well the "standard" is not something from which you can derive
any true understanding of anything.

I certainly can. I don't know what your problem is.

That's like saying spelling bee champions are expert linguists. A
language standard that goes out of its way to avoid the word variable
seems to me like it maybe has been built on questionable premises.

Not really. The C standard uses the word "object", and describes
properties that objects have. I truly don't see how introducing the
word "variable" (presumably variables are a subset of objects?) would
be helpful.

The fact that certain hunks of data can exist should be a seperate
concept to a variable it happens to be sitting in. A *variable* can
cause a hunk of data to inherit const semantics at run time while a
hunk of data intrinsically in of itsef cannot change its const
semantics. So this distinction kind of matters, and it means knowing
the difference between variables, and "objects" is a prerequisite for
"getting" this.

So for example, if you have an inline string, can you return it from a
function? It depends on the attributes of the *variable* it was first
bound to. It can be returned if it was stuck in a char *, but *not* if
it is stuck in a char[]. How does one think about this without
understanding that its through the variable declaration that we
determine this?

By understanding the attributes of the objects that the program is
operating on.

By "inline string", I assume you mean a string literal. A string
literal corresponds to a static object with certain attributes as
defined in the standard. If it's "stuck in a char*", then you have an
object of type char* that points to the object.

Well, more than that you have implicit storage. The inline string has
to actually exist as a wad of data somewhere.

[...] If it's "stuck in a
char[]", then you've copied the value of that object to another
object.

No, that's a matter of implementation.

char x[] = "xxxx";

is the same as

char x[];
memset (x, 'x', 4);
x[4] = '\0';

No, it isn't. The first form is legal; the second is not.

I think you mean:

char x[5];
memset(x, 'x', 4);
x[4] = '\0';

and a compiler might easily do that, without the requirement of the
existence of any "xxxx" "object" (actually, this is more likely with
char x[]="", for obvious reaons). Similarly, if you mismatch the size
of the array declaration with the inline string, the compiler has a
bunch of choices as to how to deal with the truncation or expansion of
the array, including the mutation of the representation of the inline
string where it is stored. Since there is no reference to the original
inline string, it does not actually have to exist, or have any property
you think it might have. There's no way for you to force the string
literal to have any particular manifestation you want it to outside of
a particular implementation.

Yes, in the case of
char x[] = "xxxx";
the compiler doesn't have to allocate storage for the string literal.

The variable x on the other hand has all sorts of properties. Note
here that in both cases, the variable declaration tells us what the
nature of the string literal's manifestation is, not the string itself.
Understanding comes from knowing what is going on with the variable,
not the string literal.

And how does calling x a "variable" rather than an "object" help
anything? x is an object that has certain properties, including a
type and a (current) value.

[...] If that object has automatic storage duration, then returning
a pointer to that object outside the object's scope can cause
undefined behavior; the origin of the value stored in that object is
no longer relevant.

This is all stuff that I learned from the standard.

Yes, but there is the question of what you didn't learn.

Of which I'm sure there's a lot. What is your point?

Its a concept from computer programming. If you are not familliar with
computer programming, you may not have heard of it, but you can't call
yourself a computer programmer, if you don't know what a variable is.

Now you're just being insulting.

Of course I know, in general terms, what a variable is. That's not
what I asked. I said I don't know *what you mean* by "variable".

It is not obvious what the word "variable" should mean in the context
of C. For example:

int x;
/*
* Obviously x is a variable.
*/
int arr[10];
/*
* arr is a variable.
* Is arr[0] a variable?
*/
struct {
int x;
int y;
} s;
/*
* Is s.x a variable?
*/
const int c = 42;
/*
* Is c a variable?
* It can't vary (unless you invoke undefined behavior).
* If c isn't a "variable", how useful is the word?
*/
int *ptr = malloc(sizeof *ptr);
/*
* Assuming ptr != NULL, is *ptr a variable?
*/

Replace "variable" by "object" in the above, and the answer to each of
these questions is clearly yes.

[...] other than that it's
apparently something distinct from an object. If you can provide a
rigorous definition of the word "variable", perhaps we can discuss
this.

Independent named storage? In C I guess it would be declared
independent named storage.

Independent of what?