«

"MisterE" <> writes:
> <> wrote in message
> news:80e656e0-4364-4ce7-8717-...
>> Consider the following snippet of code:
>>
>> int main(VOID)
>> {
>> static ushort fractionalValue[]={
>> 0, 100, 200, 300, 400, 500, 600, 700, 800, 900,
>> 250, 333, 666, 750, 0, 0
>> };
>>
>> ushort nonStatic[] = {
>> 0, 100, 200, 300, 400
>> }
>>
>> }
>>
>> I am using gcc over cygwin. I want to know where the storage for
>> "fractionalValue" would be allocated (stack or data segment) ?
>>
>> Also, where the storage for "nonStatic" would be allocated (again
>> stack or data segment) ?
>
> If it was a function and not main you would be safe to say that nonstatic
> goes onto the stack.
> However because its main and is the 'base' function, some compilers could
> put this onto the heap. THis is all implementation dependant. Even the
> static one can sometimes go into heap/stack because some processors can't
> read data from code space, instead part of the setup initialises ram with
> those values, even though they are static, many small microprocessors would
> put the static on the heap and non static on the stack.

Um, main *is* a function. Since it can be called recursively (whether
that's a good idea is a separate question), the compiler has to store
its automatically allocated local objects in some stack-like fashion
unless it can prove that main is never called recursively in the
program. But then, it can do the same kind of thing for any other
function; if the compiler (or linker?) can prove that two or more
calls to a function are active simultaneously, it can store that
function's local automatic objects in, say, the same place where
static objects are stored.

But this kind of thing is moderately difficult to detect, and in most
implementations avoiding the stack doesn't buy you anything anyway. I
don't know of any implementations that actually play that kind of
trick.

--
Keith Thompson (The_Other_Keith) <kst->
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

MisterE wrote:
>
.... snip ...
>
> If it was a function and not main you would be safe to say that
> nonstatic goes onto the stack. However because its main and is
> the 'base' function, some compilers could put this onto the heap.
> THis is all implementation dependant. Even the static one can
> sometimes go into heap/stack because some processors can't read
> data from code space, instead part of the setup initialises ram
> with those values, even though they are static, many small
> microprocessors would put the static on the heap and non static
> on the stack.

Not so. main is just another function, except that its prototype
is pre-specified. It can be called recursively, etc. Its local
variables must follow all the normal rules. For example:

[1] c:\c\junk>cat junk.c
#include <stdio.h>

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

if (argc) {
main(--argc, argv);
putchar(argc + '0');
putchar('\n');
}
return argc;
}

[1] c:\c\junk>cc junk.c

[1] c:\c\junk>.\a x y z
0
1
2
3

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

In article <>,
Keith Thompson <kst-> wrote:

>Um, main *is* a function. Since it can be called recursively (whether
>that's a good idea is a separate question), the compiler has to store
>its automatically allocated local objects in some stack-like fashion
>unless it can prove that main is never called recursively in the
>program. But then, it can do the same kind of thing for any other
>function; if the compiler (or linker?) can prove that two or more
>calls to a function are active simultaneously, it can store that
^ never
>function's local automatic objects in, say, the same place where
>static objects are stored.

In older versions of Fortran, recursion was not allowed, and it was
common to allocate fixed locations for each non-parameter variable.

-- Richard
--
:wq

On 22 Feb 2008 20:36:29 GMT, (Richard Tobin)
wrote:

> In article <>,
> Keith Thompson <kst-> wrote:
>
> >Um, main *is* a function. Since it can be called recursively (whether
> >that's a good idea is a separate question), the compiler has to store
> >its automatically allocated local objects in some stack-like fashion
> >unless it can prove that main is never called recursively in the
> >program. But then, it can do the same kind of thing for any other
> >function; if the compiler (or linker?) can prove that two or more
> >calls to a function are active simultaneously, it can store that
> ^ never
> >function's local automatic objects in, say, the same place where
> >static objects are stored.
>
> In older versions of Fortran, recursion was not allowed, and it was
> common to allocate fixed locations for each non-parameter variable.
>
To be pedantic, I'd rather say not _supported_; it wasn't required to
work, and as you note often didn't, but the implementation wasn't
required to catch it, and usually didn't, especially if indirect.

It still isn't by default -- formally you have to specify RECURSIVE.
But on most if not all modern machines, the (performance) penalty for
using stack has been eliminated or even reversed, so compilers
often(?) use it even when not formally required. Although, at least
some Fortran compilers have options to put large and/or variably-sized
arrays in heap instead, allocated and deallocated at subprogram entry
and exit, because of (primarily) OSes that have stack size limits
small relative to that for the heap and also (importantly) the sizes
of data many Fortran programmers want to handle.

COBOL at least through 1985 also doesn't support recursion.

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