[C99] local VLA with dimension given by a global var?

[MackS]

The system I am working on supports a subset of C99, among which
"standard-compliant VLAs".

I've already learnt that VLAs can't have global scope. My question is
whether I can safely declare a (local) VLA to have as its dimension a
global variable of type int:

short dim;

int main(void)
{

/* (...), possibly access/change value of dim */

{
int vla[dim];
}

/* (...) */

return 0;

}

If I understand the vary basics of how the compiler works this is a
trivial question, ie, in the code above the variable dim is just being
evaluated at that point and its value *at that point in time* is being
used to define the dimension of the array; is this correct? Ie, can I
safely this?

Thank you,

Mack

[j]

"MackS" <ma***********@ hotmail.com> wrote in message
news:11******** **************@ c13g2000cwb.goo glegroups.com.. .

The system I am working on supports a subset of C99, among which
"standard-compliant VLAs".

I've already learnt that VLAs can't have global scope. My question is
whether I can safely declare a (local) VLA to have as its dimension a
global variable of type int:

short dim;

int main(void)
{

/* (...), possibly access/change value of dim */

{
int vla[dim];
}

/* (...) */

return 0;

}

If I understand the vary basics of how the compiler works this is a
trivial question, ie, in the code above the variable dim is just being
evaluated at that point and its value *at that point in time* is being
used to define the dimension of the array; is this correct? Ie, can I
safely this?

Thank you,

Mack

Yes, this is perfectly fine. 6.7.5.2#9 illustrates this.

--
j

[Jack Klein]

On 19 Feb 2005 09:06:40 -0800, "MackS" <ma***********@ hotmail.com>
wrote in comp.lang.c:

The system I am working on supports a subset of C99, among which
"standard-compliant VLAs".

I've already learnt that VLAs can't have global scope. My question is
It has nothing to do with scope, it has to do with storage duration.
VLAs must have automatic storage duration, and can't have static
storage duration.
whether I can safely declare a (local) VLA to have as its dimension a
global variable of type int:

short dim;

int main(void)
{

/* (...), possibly access/change value of dim */

{
int vla[dim];
}

/* (...) */

return 0;

}

If I understand the vary basics of how the compiler works this is a
trivial question, ie, in the code above the variable dim is just being
evaluated at that point and its value *at that point in time* is being
used to define the dimension of the array; is this correct? Ie, can I
safely this?

Yes, the size of the VLA will be the value that the expression
evaluates to at the time the array is created.

--
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/~a...FAQ-acllc.html

[Zeljko Vrba]

On 2005-02-19, Jack Klein <ja*******@spam cop.net> wrote:

It has nothing to do with scope, it has to do with storage duration.
VLAs must have automatic storage duration, and can't have static
storage duration.

Speaking of VLAs..

It seems that the standard doesn't specify how VLAs are implemented, although
the most obvious ways are:
1. stack (like the non-portable alloca())
2. malloc() on the heap

In both cases you can declare an absurdly large VLA so that there isn't enough
memory to allocate it. I haven't been able to find in the C99 standard what
happens then..

So what is the 'standard' way to handle an out-of-memory condition for VLAs?
There is no place to 'return NULL' as malloc() does..

[Michael Mair]

Zeljko Vrba wrote:

On 2005-02-19, Jack Klein <ja*******@spam cop.net> wrote:

It has nothing to do with scope, it has to do with storage duration.
VLAs must have automatic storage duration, and can't have static
storage duration.

Speaking of VLAs..

It seems that the standard doesn't specify how VLAs are implemented, although
the most obvious ways are:
1. stack (like the non-portable alloca())
2. malloc() on the heap

In both cases you can declare an absurdly large VLA so that there isn't enough
memory to allocate it. I haven't been able to find in the C99 standard what
happens then..

So what is the 'standard' way to handle an out-of-memory condition for VLAs?
There is no place to 'return NULL' as malloc() does..

As this is not your problem but the implementation' s:
The program will die. If you are lucky, it will do so in a verbose
way. I would not nurse any expectations beyond a size of 64K...

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Zeljko Vrba]

On 2005-02-20, Michael Mair <Mi**********@i nvalid.invalid> wrote:

As this is not your problem but the implementation' s:
The program will die. If you are lucky, it will do so in a verbose
way. I would not nurse any expectations beyond a size of 64K...

OK, I'm not trying to start a flame here, but why would anyone use VLAs when
they are not guaranteed to always work and you cannot detect that? In all other
aspects of C the programmer is given a chance to handle the error (extending
your line of thought - why check for malloc() returning NULL? the library coud
just terminate the program..)

I think this is a crucial point missing from the standard. The standard
commitee should have taken this into account and specify some kind of
standard behaviour that is under programmer's control (e.g. delivery of a
signal for which a signal handler can be written, at least in the hosted
environments). Otherwise, each implementation will choose its own way of
letting the programmer know about the memory allocation failure (e.g.
#pragma VLA_alloc_failu re(handler_func ) and similar..) and soon there could
be several incompatible implementations and the C99 code which uses custom VLA
error handling as an extension won't be portable accross them any more..

What's worse, the implementation can *never* guarantee ANY size of VLA because
it depends on the current runtime environment (e.g. in one environment I could
possibly get 16M VLA, and in the other I couldn't get even 64k).

You can't even know in advance the maximum amount of memory needed for VLAs
so it could be preallocated at program startup (or the execution fails if it
can't be preallocated).

IMHO, these points combined with the absence of any standardized error handling
for VLA memory allocation failure makes them completely useless for programming
a seroius and robust application. It would be better if alloca() were
standardized.

[Chris Croughton]

On Sun, 20 Feb 2005 08:05:50 +0000 (UTC), Zeljko Vrba
<mo****@fly.srk .fer.hr> wrote:

On 2005-02-19, Jack Klein <ja*******@spam cop.net> wrote:

It has nothing to do with scope, it has to do with storage duration.
VLAs must have automatic storage duration, and can't have static
storage duration.
Speaking of VLAs..

It seems that the standard doesn't specify how VLAs are implemented, although
the most obvious ways are:
1. stack (like the non-portable alloca())
2. malloc() on the heap

A VLA has storage wherever it is used. If you say:

void func(int n)
{
char buff[n];
int x;
...
}

then both x and buff will be allocated in 'automatic' storage (whether
that is on "the stack" depends on whether that's what your compiler
uses).
In both cases you can declare an absurdly large VLA so that there isn't enough
memory to allocate it. I haven't been able to find in the C99 standard what
happens then..
Whatever usually happens when you allocate too much storage. It's
exactly the same as if you declared a fixed length array of the same
size (whatever you system does when it runs out of stack, for instance).
So what is the 'standard' way to handle an out-of-memory condition for VLAs?
There is no place to 'return NULL' as malloc() does..

There isn't one, the same as there isn't a 'standard' way to handle
recursion too deep, or declaring a 2GB 'normal' array in automatic
storage. If you are lucky your program will crash with a system error
and a core dump, if you are unlucky demons will erupt from your computer
and drag you down to the uttermost depths of world slime. The only
difference is that a compiler /might/ be able to trap a silly array size
at compile time with a fixed array (it doesn't have to, but it could be
done).

If you're really lucky the system will say "Oh, you want 57 petabytes of
memory? OK, I'll just go out and buy some for you, wait around a few
years..."

Chris C

[Michael Mair]

Zeljko Vrba wrote:

On 2005-02-20, Michael Mair <Mi**********@i nvalid.invalid> wrote:

As this is not your problem but the implementation' s:
The program will die. If you are lucky, it will do so in a verbose
way. I would not nurse any expectations beyond a size of 64K...

OK, I'm not trying to start a flame here, but why would anyone use VLAs when
they are not guaranteed to always work and you cannot detect that? In all other
aspects of C the programmer is given a chance to handle the error (extending
your line of thought - why check for malloc() returning NULL? the library coud
just terminate the program..)

I think this is a crucial point missing from the standard. The standard
commitee should have taken this into account and specify some kind of
standard behaviour that is under programmer's control (e.g. delivery of a
signal for which a signal handler can be written, at least in the hosted
environments). Otherwise, each implementation will choose its own way of
letting the programmer know about the memory allocation failure (e.g.
#pragma VLA_alloc_failu re(handler_func ) and similar..) and soon there could
be several incompatible implementations and the C99 code which uses custom VLA
error handling as an extension won't be portable accross them any more..

What's worse, the implementation can *never* guarantee ANY size of VLA because
it depends on the current runtime environment (e.g. in one environment I could
possibly get 16M VLA, and in the other I couldn't get even 64k).

You can't even know in advance the maximum amount of memory needed for VLAs
so it could be preallocated at program startup (or the execution fails if it
can't be preallocated).

IMHO, these points combined with the absence of any standardized error handling
for VLA memory allocation failure makes them completely useless for programming
a seroius and robust application. It would be better if alloca() were
standardized.

In a way, you are right. However, even

double array[7000][7000];

can die at runtime without telling you why and while you still
have enough memory left...
If we added checks and safeguards and error states for each and
everything, then this new C would probably suffer from an even worse
lack of popularity than C99.

Back to VLAs: IMO, they are quite nice for reasonably small array
sizes but for larger array sizes I would always suggest to handle the
memory yourself i.e. explicitly allocate it and maybe implement a sparse
structure.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Chris Croughton]

On Sun, 20 Feb 2005 11:48:15 +0000 (UTC), Zeljko Vrba
<mo****@fly.srk .fer.hr> wrote:

On 2005-02-20, Michael Mair <Mi**********@i nvalid.invalid> wrote:

As this is not your problem but the implementation' s:
The program will die. If you are lucky, it will do so in a verbose
way. I would not nurse any expectations beyond a size of 64K...
OK, I'm not trying to start a flame here, but why would anyone use VLAs when
they are not guaranteed to always work and you cannot detect that? In all other
aspects of C the programmer is given a chance to handle the error (extending
your line of thought - why check for malloc() returning NULL? the library coud
just terminate the program..)

No, if you do

int main(int argc, char **argv)
{
long array[10000][10000];
printf("Hello world\n");
return 0;
}

then that is equally likely to fail at runtime with no way of catching
the error (trying to allocate 400 MB or more on the stack will probably
blow it). There is no difference. Or for that matter:

void func(int depth)
{
long array[10000];
if (depth > 0)
func(depth - 1);
}

int main(int argc, char **argv)
{
func(10000);
printf("Hello world\n");
return 0;
}

(it will run out of stack in the recursion).
I think this is a crucial point missing from the standard. The standard
commitee should have taken this into account and specify some kind of
standard behaviour that is under programmer's control (e.g. delivery of a
signal for which a signal handler can be written, at least in the hosted
environments). Otherwise, each implementation will choose its own way of
letting the programmer know about the memory allocation failure (e.g.
#pragma VLA_alloc_failu re(handler_func ) and similar..) and soon there could
be several incompatible implementations and the C99 code which uses custom VLA
error handling as an extension won't be portable accross them any more..
No, it is very unlikely that any implementors will put in any error
handling for it at all. As I pointed out above, there's nothing to stop
a program from trying to allocate too much on the stack with fixed
length arrays, why should VLAs be any different?

Note that in the version of the language which allows VLAs (C99) it is
also allowed to declare variables after other code:

void func(int len)
{
if (len < 1000)
{
int array[len];
/* do stuff */
}
else
{
/* do failure stuff */
}
}

If you try to force compilers (in the standard) to put in code to catch
every error then the code size will increase and the speed will drop and
you will find that no one uses the language.
What's worse, the implementation can *never* guarantee ANY size of VLA because
it depends on the current runtime environment (e.g. in one environment I could
possibly get 16M VLA, and in the other I couldn't get even 64k).
Yup. The same is true of any automatic variables. I have code which
assumes that a function can allocate a 16kB buffer locally, it will
break on some systems (on the systems where it is intended to run it is
safe, because I know that the stack is big enough there).
You can't even know in advance the maximum amount of memory needed for VLAs
so it could be preallocated at program startup (or the execution fails if it
can't be preallocated).
Nope. You can't know in advance anything at all about the system at run
time, it might crash just trying to load your program. We live in an
uncertain universe...
IMHO, these points combined with the absence of any standardized error handling
for VLA memory allocation failure makes them completely useless for programming
a seroius and robust application. It would be better if alloca() were
standardized.

Except that there are systems on which alloca() is difficult to
implement reliably as well (some programs test at install time whether
alloca() works and use a different mechanism if it doesn't), so the
standard would have to allow alloca() to always fail.

Personally, I think that all of the C99 features are pretty useless
until it can be reasonably guaranteed that almost everywhere will have a
conforming compiler and library. At the moment I can't portably use
VLAs, late declaration of variables, long long or many other features
I'd rather like to use...

Chris C

[Keith Thompson]

Michael Mair <Mi**********@i nvalid.invalid> writes:

Zeljko Vrba wrote:

[...]

Speaking of VLAs.. It seems that the standard doesn't specify how
VLAs are implemented, although
the most obvious ways are:
1. stack (like the non-portable alloca())
2. malloc() on the heap
In both cases you can declare an absurdly large VLA so that there
isn't enough memory to allocate it. I haven't been able to find in
the C99 standard what happens then.. So what is the 'standard' way
to handle an out-of-memory condition for VLAs? There is no place
to 'return NULL' as malloc() does..

As this is not your problem but the implementation' s:
The program will die. If you are lucky, it will do so in a verbose
way. I would not nurse any expectations beyond a size of 64K...

You can't assume that the program will die. Running out of memory for
a VLA invokes undefined behavior, just like running out of memory for
any other automatic variable.

Probably the only way to fix this would be to define a general
exception-handling mechanism for C, and require that running out of
space raises an exception that can be handled by the caller. (You
could provide some specific mechanism for VLAs, but that would be ugly
IMHO, since it wouldn't handle overflows for constant-sized arrays.)

--
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.