where the storage will be allocated

Discussion in 'C Programming' started by junky_fellow@yahoo.co.in, Feb 22, 2008.

  1. Guest

    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..
    , Feb 22, 2008
    #1
    1. Advertising

  2. <> wrote in message
    news:...

    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.
    David T. Ashley, Feb 22, 2008
    #2
    1. Advertising

  3. Ian Collins Guest

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

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

    --
    Ian Collins.
    Ian Collins, Feb 22, 2008
    #3
  4. CBFalconer Guest

    Ian Collins wrote:
    > 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
    >> "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.

    --
    [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
    CBFalconer, Feb 22, 2008
    #4
  5. santosh Guest

    wrote:

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

    > thanks for any help..
    santosh, Feb 22, 2008
    #5
  6. santosh Guest

    CBFalconer wrote:

    > Ian Collins wrote:
    >> 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
    >>> "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.
    santosh, Feb 22, 2008
    #6
  7. MisterE Guest

    <> wrote in message
    news:...
    > 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.
    MisterE, Feb 22, 2008
    #7
  8. Ian Collins Guest

    CBFalconer wrote:
    > Ian Collins wrote:
    >> 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
    >>> "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.
    Ian Collins, Feb 22, 2008
    #8
  9. Ian Collins Guest

    MisterE wrote:
    > <> wrote in message
    > news:...
    >> 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.

    --
    Ian Collins.
    Ian Collins, Feb 22, 2008
    #9
  10. Richard Guest

    CBFalconer <> writes:

    > Ian Collins wrote:
    >> 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
    >>> "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?
    Richard, Feb 22, 2008
    #10
  11. "MisterE" <> writes:
    > <> wrote in message
    > news:...
    >> 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) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Feb 22, 2008
    #11
  12. CBFalconer Guest

    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
    CBFalconer, Feb 22, 2008
    #12
  13. In article <>,
    Keith Thompson <> 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
    Richard Tobin, Feb 22, 2008
    #13
  14. On 22 Feb 2008 20:36:29 GMT, (Richard Tobin)
    wrote:

    > In article <>,
    > Keith Thompson <> 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
    David Thompson, Mar 2, 2008
    #14
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Duncan
    Replies:
    0
    Views:
    388
    Duncan
    Jul 21, 2003
  2. Laura Heinzmann

    How to check memory size allocated to JVM?

    Laura Heinzmann, Feb 16, 2005, in forum: Java
    Replies:
    1
    Views:
    8,156
    John McGrath
    Feb 16, 2005
  3. Davide
    Replies:
    10
    Views:
    692
    Oliver Wong
    Jan 10, 2006
  4. Replies:
    5
    Views:
    616
    Matt Wharton
    Dec 9, 2004
  5. sarathy
    Replies:
    2
    Views:
    658
    sarathy
    Jul 17, 2006
Loading...

Share This Page