where the storage will be allocated

[junky_fellow]

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

 

[David T. Ashley]

My responses below assume a "typical" compiler and development tool chain.

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) ?

fractionalValue will go into a data segment. The reason is that it has to
persist across function calls. (Although main() is a special case, most
compilers don't care -- they treat main() just like any other function.)

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

This will typically go on the stack. The reason is that it does not have to
persist across function calls.

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 ?

For storage class automatic (variables on the stack), typically the compiler
will generate code to reinitialize the variables every time the function is
entered.

Note that in your example, "fractionalValue" and "nonStatic" are initialized
in qualitatively different ways. The former normally has its data defined
so it gets loaded once as the program starts, and the latter usually has
code added by the compiler at the start of the function to assign the
variable each time the function starts. The mechanisms are normally VERY
diferent.

Most of your questions can be resolved by examining the assembly-language
output of the compiler.

Dave.

 

[Ian Collins]

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

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

 

[CBFalconer]

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

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

No it isn't. First, he needs to #define ushort. I am assuming as
"unsigned short". Then, a static variable (i.e. fractionalValue)
declared within a function is only visible within that functions,
but is kept in memory that is pre-initialized (i.e. before the
program begins to run) and which lasts until the program exits.
Without the 'static' word the object (i.e. nonStatic) is assigned
memory when the function is entered, and that memory is deassigned
when the function exits. This latter is automatic storage, and
that is all the program writer needs to know about it.

 

[santosh]

Guys,

Consider the following snippet of code:

int main(VOID)

What is 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) ?

Implementation dependant. A debugger will show you where it is for a
particular run under a particular system. The C Standard only talks
about scope and linkage, nothing about placement in memory.

But for typical desktop systems fractionalValue is likely to be located
in the program's "data segment".

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

Again the C Standard does not specify any such requirement, but having
said that, under most implementations automatic objects are likely to
be on the stack.

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 ?

Here we come to code emission strategies which are *really* specific to
implementations and there is not much that we can say in general. The
usual method for allocations on the stack is a stack pointer decrement
followed by instructions that load the appropriate data into the newly
created space. For regular data a loop can be used. Random data will
require more instructions to generate.

For data to be placed in the data segment, it is usually "embedded" into
the executable itself and loaded by the program loader. Uninitialised
static data objects might not be represented fully in the executable
file but might be "created" during the loading process and initialised
to zeroes by the loader.

Importantly the code is likely to very different with and without
optimisations.

Since all of this is totally system specific why don't you examine the
assembler output of your implementation instead of asking here?

 

[santosh]

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

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

No it isn't. First, he needs to #define ushort. I am assuming as
"unsigned short". Then, a static variable (i.e. fractionalValue)
declared within a function is only visible within that functions,
but is kept in memory that is pre-initialized (i.e. before the
program begins to run) and which lasts until the program exits.
Without the 'static' word the object (i.e. nonStatic) is assigned
memory when the function is entered, and that memory is deassigned
when the function exits. This latter is automatic storage, and
that is all the program writer needs to know about it.

Note that the OP is asking *where* in memory both the objects would be
placed. That, AFAICS, *is* implementation dependent.

 

[MisterE]

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

 

[Ian Collins]

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
"fractionalValue" 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]

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
"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,

What? That sounds like complete bollocks to me.

 

[Richard]

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

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

No it isn't. First, he needs to #define ushort. I am assuming as

Yes it is. Did you even READ his question before piling in with your
uninformed and, as usual, incorrect opinions?

 

[Keith Thompson]

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.

 

[CBFalconer]

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

 

[Richard Tobin]

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

 

[David Thompson]

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