Another silly question: array with vars

[Sensei]

Hi again! I have ``yet another silly question'', about arrays this time.

I've looked through the FAQs in the array & memory sections without
finding an answer. I surely didn't look deep enough.

What does the standards (plural! C99 and pre-C99 standards) say about
variable-initialized arrays like in the following code?

int main(void)
{
int a = 6;
char s[a];
/* ... */
return 0;
}

If my memory doesn't fail, that is not pre-C99 compliant and resulting
in a compiler error, but I'm not sure... And does C99 state something
about the initializer ``int a''? I mean, what if it is NOT initialized?

I know, curiosity killed the cat

 

[Mike Wahler]

Hi again! I have ``yet another silly question'', about arrays this time.

I've looked through the FAQs in the array & memory sections without
finding an answer. I surely didn't look deep enough.

What does the standards (plural! C99 and pre-C99 standards) say about
variable-initialized arrays like in the following code?

int main(void)
{
int a = 6;
char s[a];
/* ... */
return 0;
}

If my memory doesn't fail, that is not pre-C99 compliant and resulting in
a compiler error, but I'm not sure...

That's correct. The array's size must be specified
by a constant expression. In the code above, 'a' is not.

And does C99 state something about the initializer ``int a''?

'int a' is not an initializer, it's a declaration (as well
as a definition).

I mean, what if it is NOT initialized?

If an object is not initialized or assigned a valid value, evaluating
its value in any context produces undefined behavior.

-Mike

 

[Guest]

If an object is not initialized or assigned a valid value, evaluating
its value in any context produces undefined behavior.

Actually, C99 changed the rules on that. The value of an uninitialised
object is indeterminate. An indeterminate value may be either an
unspecified but valid value, or a trap representation. If the type has
no trap representations, there is no possible undefined behaviour in
reading the object.

 

[Keith Thompson]

What does the standards (plural! C99 and pre-C99 standards) say about
variable-initialized arrays like in the following code?

int main(void)
{
int a = 6;
char s[a];
/* ... */
return 0;
}

If my memory doesn't fail, that is not pre-C99 compliant and resulting
in a compiler error, but I'm not sure... And does C99 state something
about the initializer ``int a''? I mean, what if it is NOT initialized?

s is a variable *length* array, not a variable initialized array; it's
also referred to as a VLA.

VLAs were introduced in C99. C90 does not support them.

If "a" were not initialized, any attempt to access its value,
including using it in a VLA declaration, would invoke undefined
behavior.

 

[Keith Thompson]

What does the standards (plural! C99 and pre-C99 standards) say about
variable-initialized arrays like in the following code?

int main(void)
{
int a = 6;
char s[a];
/* ... */
return 0;
}

If my memory doesn't fail, that is not pre-C99 compliant and resulting
in a compiler error, but I'm not sure... And does C99 state something
about the initializer ``int a''? I mean, what if it is NOT initialized?

s is a variable *length* array, not a variable initialized array; it's
also referred to as a VLA.

VLAs were introduced in C99. C90 does not support them.

If "a" were not initialized, any attempt to access its value,
including using it in a VLA declaration, would invoke undefined
behavior.

As Harald points out, accessing an int object probably doesn't invoke
UB if int has no trap representations (and it's possible for a program
to prove that it doesn't by looking at CHAR_BIT*sizeof(int), INT_MIN,
and INT_MAX). But it's still a Very Bad Idea. In this case, it's
likely to result in either undefined behavior if "a" happens to be
negative, or stack overflow^H^H^H^H^H^H^H^H^H^H^H^H^H^H an attempt to
create an object whose size exceeds implementation limits (and, again,
undefined behavior) if the value of "a" happens to be large.

And let me issue a plea to avoid the use of "a" as an identifier in
sample code, or of any other identifier that can easily be confused
with an English word. "x" and "s" are ok.

 

[Sensei]

Actually, C99 changed the rules on that. The value of an uninitialised
object is indeterminate. An indeterminate value may be either an
unspecified but valid value, or a trap representation. If the type has
no trap representations, there is no possible undefined behaviour in
reading the object.

Then

int i;
int array;

does not invoke an UB, but does C99 say anything about the actual
storage? From some trials I'd say that compilers usually allocate a
certain amount of memory, but I don't know if this is against the
standard or not.

 

[Sensei]

As Harald points out, accessing an int object probably doesn't invoke
UB if int has no trap representations (and it's possible for a program
to prove that it doesn't by looking at CHAR_BIT*sizeof(int), INT_MIN,
and INT_MAX). But it's still a Very Bad Idea. In this case, it's
likely to result in either undefined behavior if "a" happens to be
negative, or stack overflow^H^H^H^H^H^H^H^H^H^H^H^H^H^H an attempt to
create an object whose size exceeds implementation limits (and, again,
undefined behavior) if the value of "a" happens to be large.

One more thing, weren't simple types as int, char, and so on
initialized to 0 with C99? I remember reading this somewhere, and of
course I might be completely wrong.

And let me issue a plea to avoid the use of "a" as an identifier in
sample code, or of any other identifier that can easily be confused
with an English word. "x" and "s" are ok.

Ok, I'll do that

 

[Ian Collins]

One more thing, weren't simple types as int, char, and so on initialized
to 0 with C99? I remember reading this somewhere, and of course I might
be completely wrong.

Not for automatic objects, the value is indeterminate. Maybe you where
thinking of compound initialisers?

 

[Ian Collins]

Actually, C99 changed the rules on that. The value of an uninitialised
object is indeterminate. An indeterminate value may be either an
unspecified but valid value, or a trap representation. If the type has
no trap representations, there is no possible undefined behaviour in
reading the object.

Then

int i;
int array;

does not invoke an UB, but does C99 say anything about the actual
storage? From some trials I'd say that compilers usually allocate a
certain amount of memory, but I don't know if this is against the
standard or not.

Well considering i can hold any value, it's pot luck how big a array you
get and due to the lack of error reporting with VLAs, attempting to use
the array may do odd things.

 

[Sensei]

Not for automatic objects, the value is indeterminate. Maybe you where
thinking of compound initialisers?

Probably I'm just confusing the two. Thanks, you've been really clear!

 

[HyperCube]

Hi again! I have ``yet another silly question'', about arrays this time.

I've looked through the FAQs in the array & memory sections without
finding an answer. I surely didn't look deep enough.

What does the standards (plural! C99 and pre-C99 standards) say about
variable-initialized arrays like in the following code?

int main(void)
{
int a = 6;
char s[a];
/* ... */
return 0;

}If my memory doesn't fail, that is not pre-C99 compliant and resulting
in a compiler error, but I'm not sure... And does C99 state something
about the initializer ``int a''? I mean, what if it is NOT initialized?

I know, curiosity killed the cat

--
Sensei <senseiwa@Apple's mail>

Research (n.): a discovery already published by a chinese guy one month
before you, copying a russian who did it in the 60s.

i think (... i'm sure) you HVAE TO use a 'constant' to specify the size
of a array, because the memory space of the array will be allocate
before the program start to run, and at that time, the value of your
variable 'a' is not known yet.

 

[Keith Thompson]

Hi again! I have ``yet another silly question'', about arrays this time.

I've looked through the FAQs in the array & memory sections without
finding an answer. I surely didn't look deep enough.

What does the standards (plural! C99 and pre-C99 standards) say about
variable-initialized arrays like in the following code?

int main(void)
{
int a = 6;
char s[a];
/* ... */
return 0;

}If my memory doesn't fail, that is not pre-C99 compliant and resulting
in a compiler error, but I'm not sure... And does C99 state something
about the initializer ``int a''? I mean, what if it is NOT initialized?

[...]

i think (... i'm sure) you HVAE TO use a 'constant' to specify the size
of a array, because the memory space of the array will be allocate
before the program start to run, and at that time, the value of your
variable 'a' is not known yet.

Nope.

The array "s" is inside a function, so memory for it is allocated when
the function is called, not on program startup. The distinction is a
subtle one for main(), but it still aplies.

C99 supports variable-length arrays (VLAs).

This has been mentioned in this thread.