where the storage will be allocated

[junky_fellow@yahoo.co.in]

Guys,

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
"fractionalValu e" would be allocated (stack or data segment) ?

Also, where the storage for "nonStatic" would be allocated (again
stack or data segment) ?

Also, if storage is allocated on stack for any of them, how the values
that
were initialized at compile time are obtained ? I mean to there have
to be
some space allocated in th executable during compile time, where the
initialized values should be stored.
Or the compiler generate a code, that would allocate space on the
stack and
put all the initial values on the stack ?

thanks for any help..

[Ian Collins]

Re: where the storage will be allocated

junky_fellow@ya hoo.co.in wrote:

Guys,
>
Consider the following snippet of code:
>
int main(VOID)

What's that?

{
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
"fractionalValu e" would be allocated (stack or data segment) ?
>

That's a platform/compiler issue, lot a language one.

--
Ian Collins.

[MisterE]

Re: where the storage will be allocated


<junky_fellow@y ahoo.co.inwrote in message
news:80e656e0-4364-4ce7-8717-0ef6524405d3@f4 7g2000hsd.googl egroups.com...

Guys,
>
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
"fractionalValu e" 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.

[Ian Collins]

Re: where the storage will be allocated

CBFalconer wrote:

Ian Collins wrote:

>junky_fellow@ya hoo.co.in wrote:
>>

>> Consider the following snippet of code:
>>>
>>int main(VOID) {

>What's that?

>
A silly mistake.

>> 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
>>"fractionalVa lue" would be allocated (stack or data segment) ?
>>>

>That's a platform/compiler issue, lot a language one.

>
No it isn't.

Oh yes it is - the OP asks where the storage is allocated, which is
platform/compiler specific.

--
Ian Collins.

[Ian Collins]

Re: where the storage will be allocated

MisterE wrote:

<junky_fellow@y ahoo.co.inwrote in message
news:80e656e0-4364-4ce7-8717-0ef6524405d3@f4 7g2000hsd.googl egroups.com...

>Guys,
>>
> 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
>"fractionalVal ue" 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,

What? That sounds like complete bollocks to me.

--
Ian Collins.

[Keith Thompson]

Re: where the storage will be allocated

"MisterE" <voids@sometwhe r.worldwrites:

<junky_fellow@y ahoo.co.inwrote in message
news:80e656e0-4364-4ce7-8717-0ef6524405d3@f4 7g2000hsd.googl egroups.com...

> 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
>"fractionalVal ue" 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_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Re: where the storage will be allocated

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

[Richard Tobin]

Re: where the storage will be allocated

In article <87lk5ckhpt.fsf @kvetch.smov.or g>,
Keith Thompson <kst-u@mib.orgwrote:

>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

[David Thompson]

Re: where the storage will be allocated

On 22 Feb 2008 20:36:29 GMT, richard@cogsci. ed.ac.uk (Richard Tobin)
wrote:

In article <87lk5ckhpt.fsf @kvetch.smov.or g>,
Keith Thompson <kst-u@mib.orgwrote:
>

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