Array size in run time

H

Heriberto Bens

Hi, friends.

I've seen the following code in an example:

int fun(int n)
{
int i, x[n];

for (i = 0; i < n; i++)
x = 5;

for (i = 0; i < n; i++)
printf("%i\n", x);
}

main()
{
fun(10);
}


As you can see, array x size depends on the argument of the function fun.
I thought this was not possible as local variables are located in the
stack, and the compiler should know what size they are going to take.

I have compiled the code and seems to work ok, but I don't know if it's
correct and will always run ok.

Is it possible to make this kind of things? If it is, is
it better to work like that rather than using malloc()?

Thanks a lot.
 
W

Walter Roberson

Heriberto Bens said:
I've seen the following code in an example:
int fun(int n)
{
int i, x[n];
for (i = 0; i < n; i++)
x = 5;
for (i = 0; i < n; i++)
printf("%i\n", x);
}
main()
{
fun(10);
}

As you can see, array x size depends on the argument of the function fun.
I thought this was not possible as local variables are located in the
stack, and the compiler should know what size they are going to take.

C99 VLA (Variable Length Arrays). Legal in C99, not legal in C89.
See also "the struct hack" for something that works in a number of
C89 implementations.
 
R

rohan.ullal

Hi, friends.

I've seen the following code in an example:

int fun(int n)
{
int i, x[n];

for (i = 0; i < n; i++)
x = 5;

for (i = 0; i < n; i++)
printf("%i\n", x);

}

main()
{
fun(10);

}

As you can see, array x size depends on the argument of the function fun.
I thought this was not possible as local variables are located in the
stack, and the compiler should know what size they are going to take.

I have compiled the code and seems to work ok, but I don't know if it's
correct and will always run ok.

Is it possible to make this kind of things? If it is, is
it better to work like that rather than using malloc()?

Thanks a lot.


I do not think that it is possible with the ANSI C language this will
make the stack handling complicated ...
 
W

Walter Roberson

int fun(int n)
{
int i, x[n]; [...]
}
As you can see, array x size depends on the argument of the function fun.
I do not think that it is possible with the ANSI C language this will
make the stack handling complicated ...

You are correct if by "ANSI C" you mean specifically
X3.159-1989, also known as C89. Some sections of that ANSI standard
were renumbered and the result was adopted by ISO in 1990, and
(if I recall correctly) ANSI then adopted the ISO version. I believe
(possibly incorrectly) that the next major C standard, known usually
as C99, is an ISO standard, and possibly not an ANSI standard.

X3.159-1989 does not know about variable length arrays (VLAs).
ISO C99 *does* know about VLAs.
 
F

Flash Gordon

Hi, friends.

I've seen the following code in an example:

int fun(int n)
{
int i, x[n];

<snip>

Either declare the function as void or return the int you have said it
returns.

Implicit int is not allowed in C99, the latest version of the C
standard. You have to be explicit about the return type.

int main(void)

It is also better, but not required, to be explicit about not taking
parameters.

The return type of main is int therefore it is best to return an int.
return 0;
I do not think that it is possible with the ANSI C language this will
make the stack handling complicated ...

You should have read Walter's reply before posting especially as it was
sitting there on Google (through which you posted) for you to read. C99
*does* allow Variable Length Arrays (VLAs). Since ANSI (America) adopted
the ISO (International) standard this qualifies as ANSI C. Although as
there is an international standard and you are on an international group
is might be more appropriate to refer to ISO C.
 
K

Keith Thompson

int fun(int n)
{
int i, x[n]; [...]
}
As you can see, array x size depends on the argument of the function fun.
I do not think that it is possible with the ANSI C language this will
make the stack handling complicated ...

You are correct if by "ANSI C" you mean specifically
X3.159-1989, also known as C89. Some sections of that ANSI standard
were renumbered and the result was adopted by ISO in 1990, and
(if I recall correctly) ANSI then adopted the ISO version. I believe
(possibly incorrectly) that the next major C standard, known usually
as C99, is an ISO standard, and possibly not an ANSI standard.

I believe ANSI adopted the ISO C99 standard. Officially the older
C89/C90 standards are obsolete (though of course they're still very
relevant in the real world).

So strictly speaking, "ANSI C" refers to C99, though it's clearer to
refer to it as "ISO C". Due to historical practice, though, "ANSI C"
commonly refers to the language defined by the (obsolete) 1989
standard (which is identical to the language defined by the 1990
standard). It's best to refer specifically to C89, C90, or C99.
X3.159-1989 does not know about variable length arrays (VLAs).
ISO C99 *does* know about VLAs.

Yes.
 
D

David Thompson

(e-mail address removed)-cnrc.gc.ca (Walter Roberson) writes:

I believe ANSI adopted the ISO C99 standard. Officially the older
C89/C90 standards are obsolete (though of course they're still very
relevant in the real world).
ANSI definitely did adopt it, but not until about May 2000; I remember
seeing the announcement, and the 'ANSI' labelled version being added
to their webstore, at much lower cost than the ISO-only version.

Actually, to be technical, I believe it was adopted on ANSI's behalf
by the committee for computing, NCITS, which as far as I can see was
just a tweak on The Accredited Standards Committee Formerly Known As
X3, and has now changed again to _I_NCITS*. Similarly I believe it was
really JTC1SC22 which adopted 9899, on behalf of ISO and IEC.

(* Meanwhile ASC X9, banking, goes merrily on as X9. Apparently when
you have gobs of other people's money clutched in your hot little
hands, you don't worry so much about glitzing up your public image.)
So strictly speaking, "ANSI C" refers to C99, though it's clearer to
refer to it as "ISO C". Due to historical practice, though, "ANSI C"
commonly refers to the language defined by the (obsolete) 1989
standard (which is identical to the language defined by the 1990
standard). It's best to refer specifically to C89, C90, or C99.
Or C95, if you are concerned about the wchar/i18n enhancements.

- formerly david.thompson1 || achar(64) || worldnet.att.net
 
R

raxitsheth2000

Hi, friends.

I've seen the following code in an example:

int fun(int n)
{
int i, x[n];

for (i = 0; i < n; i++)
x = 5;

for (i = 0; i < n; i++)
printf("%i\n", x);

}

main()
{
fun(10);

}

As you can see, array x size depends on the argument of the function fun.
I thought this was not possible as local variables are located in the
stack, and the compiler should know what size they are going to take.

I have compiled the code and seems to work ok, but I don't know if it's
correct and will always run ok.

as many of here as already replied, its correct as per c99, but not as
per c88.

Upto my knowledge(not 100 % confirmed, but you may need to digout)
"Will always run OK" is NOT Guranted,

if you are not writing portable code and you stick to any particular
implementation of compiler you may need to ask your vendor.

if you are writing portable code for a,b,c,d compiler you may need to
refer all the vendor supports this feature or not.?

For gcc i found this link,
http://gcc.gnu.org/c99status.html
It clearly shows me variable-length arrays "Broken" status.
Is it possible to make this kind of things? If it is, is
it better to work like that rather than using malloc()?

It is possible if the compiler/platform vendor support the feature.

Or I think malloc/related functions can be used in most cases.
Thanks a lot.

--Raxit
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,767
Messages
2,569,572
Members
45,046
Latest member
Gavizuho

Latest Threads

Top