Doubt on Stack variables.

Discussion in 'C Programming' started by deepak, Jan 15, 2007.

  1. deepak

    deepak Guest

    Hi In the following function how the memory 'll be allocated.

    1) Will it allocate memory for all the char's together or allocate for
    first char. then for int then for float and after
    this only second char in the function gets memory.
    2) If i declare variables where the size of al variables gone beyond
    sizeof stack (assume it is 1000) what 'll
    happen?

    voud foo( int a, innt b)
    {

    char cb;
    int ib;
    float fc;
    int ic;
    char cc;

    }
    deepak, Jan 15, 2007
    #1
    1. Advertising

  2. >Hi In the following function how the memory 'll be allocated.

    Standard C does not dictate how. It might be by purchase order
    paid for with PayPal.

    C does not define anything called a "stack". For this question,
    it seems to refer to the place where auto variables are allocated.

    >1) Will it allocate memory for all the char's together or allocate for
    >first char. then for int then for float and after
    > this only second char in the function gets memory.


    It is not guaranteed that the variables will be allocated in reverse
    order of the translation of the variable name into Pig Latin, or
    any other particular order.

    >2) If i declare variables where the size of al variables gone beyond
    >sizeof stack (assume it is 1000) what 'll
    > happen?


    It probably won't be pretty. Expect whatever's beyond that point to
    get trashed. Then expect a mess when it's used for its original purpose.

    >voud foo( int a, innt b)

    voud? innt? Are these typedefs for doubles?

    >{
    >
    > char cb;
    > int ib;
    > float fc;
    > int ic;
    > char cc;
    >
    >}
    >
    Gordon Burditt, Jan 15, 2007
    #2
    1. Advertising

  3. "deepak" <> writes:
    > Hi In the following function how the memory 'll be allocated.
    >
    > 1) Will it allocate memory for all the char's together or allocate for
    > first char. then for int then for float and after
    > this only second char in the function gets memory.
    > 2) If i declare variables where the size of al variables gone beyond
    > sizeof stack (assume it is 1000) what 'll
    > happen?
    >
    > voud foo( int a, innt b)
    > {
    >
    > char cb;
    > int ib;
    > float fc;
    > int ic;
    > char cc;
    >
    > }


    The compiler can allocate the variables in any order it likes. If you
    write good portable code, it won't matter.

    The C standard doesn't specify a "stack" (the word doesn't even appear
    in the standard). Most compilers do use a stack for the allocation of
    local variables, but even so "sizeof stack" doesn't mean anything.

    Memory is not infinite, so eventually a program can run out of space
    to allocate local variables. The limit usually applies to the total
    current "stack" allocation for all active functions, not to the space
    for a single function. If that limit is exceeded (a "stack
    overflow"), the behavior is undefined; usually this means that the
    program terminates with an error message.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jan 15, 2007
    #3
  4. deepak

    Sourcerer Guest

    "deepak" <> wrote in message
    news:...
    >
    > Hi In the following function how the memory 'll be allocated.
    >
    > 1) Will it allocate memory for all the char's together or allocate for
    > first char. then for int then for float and after
    > this only second char in the function gets memory.
    > 2) If i declare variables where the size of al variables gone beyond
    > sizeof stack (assume it is 1000) what 'll
    > happen?
    >
    > voud foo( int a, innt b)


    I suppose this constitutes two typos? Is this correct?

    void foo(int a, int b)

    > {
    >
    > char cb;
    > int ib;
    > float fc;
    > int ic;
    > char cc;
    >
    > }


    Any order of allocation is possible.
    If your variables have consumed all stack space and you still want more, you
    might get an "out of stack space" or similar message, followed by the crash of
    your program, although some systems might not even be as generous as to give you
    the message, and won't crash only your program.

    --
    "It is easy in the world to live after the world's opinion; it easy in solitude
    to live after our own; but the great man is he who in the midst of the crowd
    keeps with perfect sweetness the independence of solitude."
    Ralph Waldo Emerson, Self-reliance 1841
    http://pinpoint.wordpress.com/
    Sourcerer, Jan 15, 2007
    #4
  5. "deepak" <> wrote in message
    news:...
    >
    > 1) Will it allocate memory for all the char's together or allocate for
    > first char. then for int then for float and after
    > this only second char in the function gets memory.


    Generally, 'C' only guarantees that a given symbol (a varialble or an array)
    is allocated contiguously. There are no guarantees about how different
    symbols are allocated with respect to each other. One cannot make
    assumptions about the address relationship between ib and ic, for example.

    As other posters have pointed out, the notion of a "stack" does not appear
    in the standards. This is probably true. In fact, some small processor
    compilers have memory models where they don't use a stack. Instead, the
    compiler analyzes the calling tree from top to bottom and puts automatics
    into a static area of memory that is shared with all functions at the same
    level of the calling tree. (This happens with the understanding that
    recursion and corecursion are disallowed.) This is attractive in small
    machines because instructions to reference memory with respect to the stack
    pointer are very expensive, and one gets smaller code size by statically
    allocating automatic variables.

    > 2) If i declare variables where the size of al variables gone beyond
    > sizeof stack (assume it is 1000) what 'll
    > happen?


    In a small machine (such as a microcontroller), bad things may happen (such
    as rolling over the stack pointer with undefined behavior). But in a larger
    machine (such as the x86 with a typical operating system),

    a)The stack limits are hard to exceed, AND

    b)The behavior is very reliable, such as program termination due to
    exceeding stack allocation.

    For a typical large machine, 1000 small variables or an array of 1000
    elements on the stack in a single function would probably be tolerated. At
    compilation, the processor has instructions to address memory in the stack
    frame with very large offsets, and usually the only limit from the
    compiler's point of view is whether it can choose the machine instructions
    it wants/needs to get to the data. At runtime, typically the stack is
    managed via the traditional virtual memory mechanisms. I doubt that a
    practical program (one designed to do a computing job rather than to test
    the stack limits) would run into these limits.

    --
    David T. Ashley ()
    http://www.e3ft.com (Consulting Home Page)
    http://www.dtashley.com (Personal Home Page)
    http://gpl.e3ft.com (GPL Publications and Projects)
    David T. Ashley, Jan 15, 2007
    #5
  6. deepak

    santosh Guest

    deepak wrote:
    > Hi In the following function how the memory 'll be allocated.
    >
    > 1) Will it allocate memory for all the char's together or allocate for
    > first char. then for int then for float and after this only second char
    > in the function gets memory.


    It is implementation dependant.

    > 2) If i declare variables where the size of al variables gone beyond
    > sizeof stack (assume it is 1000) what 'll happen?


    Firstly the C standard neither mentions nor requires a 'stack', though
    it's a common feature of most systems.

    What'll happen when you run out of stack space. Again it's
    implementation dependant, but in many cases it's likely to lead to the
    termination of your program or to corruption of memory and a crash
    later.

    > voud foo( int a, innt b)


    void foo(int a, int b)

    > {
    >
    > char cb;
    > int ib;
    > float fc;
    > int ic;
    > char cc;
    >


    It's good practise to include an explicit return even for function
    returning void.

    > }


    If you're going to include code, please take the time to correct
    obvious typos.
    santosh, Jan 15, 2007
    #6
  7. deepak

    Guest

    santosh wrote:
    > deepak wrote:
    > > Hi In the following function how the memory 'll be allocated.
    > >


    <-- snipped -->

    >
    > It's good practise to include an explicit return even for function
    > returning void.


    Is that just a coding style or are there any benefits?
    Thanks,
    p_c_g


    >
    > > }

    >
    > If you're going to include code, please take the time to correct
    > obvious typos.
    , Jan 15, 2007
    #7
  8. <> wrote in message
    news:...
    > santosh wrote:
    >> deepak wrote:
    >> > Hi In the following function how the memory 'll be allocated.
    >> >

    >
    > <-- snipped -->
    >
    >>
    >> It's good practise to include an explicit return even for function
    >> returning void.

    >
    > Is that just a coding style or are there any benefits?


    I'm going to conjecture it is just style.

    Every human being has a certain set of irrational things they do.

    In my case, I CANNOT STAND return statements without parenthesis, so you
    find code of mine that looks like this:

    return(3);

    when others would write:

    return 3;

    There is no rational reason for my bias. It may be that I learned FORTRAN
    first, or there may be some other similar reason.

    There absolutely is no rational reason to include "return" at the end of a
    function that returns void.

    --
    David T. Ashley ()
    http://www.e3ft.com (Consulting Home Page)
    http://www.dtashley.com (Personal Home Page)
    http://gpl.e3ft.com (GPL Publications and Projects)
    David T. Ashley, Jan 15, 2007
    #8
  9. In article <>,
    David T. Ashley <> wrote:
    >There absolutely is no rational reason to include "return" at the end of a
    >function that returns void.


    Sometimes it empahises (to a human reader) a parallel between case that
    might otherwise be missed, or emphasies that the flow of control reaches
    that point.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Jan 15, 2007
    #9
  10. deepak

    soccertl Guest

    deepak wrote:
    > 2) If i declare variables where the size of al variables gone beyond
    > sizeof stack (assume it is 1000) what 'll
    > happen?


    It depends on the memory model and compiler used. For example, in our
    large memory model running on OS/2, all function calls allocated a
    stack frame to put the auto variables into. If you exceeded the stack
    size by calling many functions deep into your thread, your program
    received an exception indicating you ran out of stack space. You could
    specify what stack size you wanted but the default was 4k, which was
    easily overrun in our huge program.

    So, there is not difinitive answer but a good guess would be your
    program would throw an exception.
    soccertl, Jan 15, 2007
    #10
  11. "David T. Ashley" <> writes:
    > "deepak" <> wrote in message
    > news:...
    >> 1) Will it allocate memory for all the char's together or allocate for
    >> first char. then for int then for float and after
    >> this only second char in the function gets memory.

    >
    > Generally, 'C' only guarantees that a given symbol (a varialble or an array)
    > is allocated contiguously. There are no guarantees about how different
    > symbols are allocated with respect to each other. One cannot make
    > assumptions about the address relationship between ib and ic, for example.
    >
    > As other posters have pointed out, the notion of a "stack" does not appear
    > in the standards. This is probably true. In fact, some small processor
    > compilers have memory models where they don't use a stack. Instead, the
    > compiler analyzes the calling tree from top to bottom and puts automatics
    > into a static area of memory that is shared with all functions at the same
    > level of the calling tree. (This happens with the understanding that
    > recursion and corecursion are disallowed.) This is attractive in small
    > machines because instructions to reference memory with respect to the stack
    > pointer are very expensive, and one gets smaller code size by statically
    > allocating automatic variables.


    A conforming implementation must support recursion; it's not optional.
    A compiler can allocate local (block-scope) variables statically *if*
    it can prove that there will be no recursive calls to that function
    (and it presumably will do so only if there's some advantage). A
    compiler can have an option that forbids recursion, but it will be
    non-conforming in that mode; it might nevertheless be useful.

    Assuming support for recursion, an implementation *must* allocate
    local variables in a stack-like fashion (last in first out). But the
    term "stack", and particularly the phrase "the stack", usually refers
    to a *contiguous* region of memory indexed by a "stack pointer" which
    is typically a CPU register. The kind of "stack" is very common, but
    it's no required by the standard. Someone here has mentioned an IBM
    mainframe operating system in which the space for a called function is
    allocated as if by calling malloc().

    [...]

    > For a typical large machine, 1000 small variables or an array of
    > 1000 elements on the stack in a single function would probably be
    > tolerated. At compilation, the processor has instructions to
    > address memory in the stack frame with very large offsets, and
    > usually the only limit from the compiler's point of view is whether
    > it can choose the machine instructions it wants/needs to get to the
    > data. At runtime, typically the stack is managed via the
    > traditional virtual memory mechanisms. I doubt that a practical
    > program (one designed to do a computing job rather than to test the
    > stack limits) would run into these limits.


    A recursive program can easily exceed any finite stack size or other
    memory limit, either due to a logical error or because it's asked to
    process a large amount of input data. And multi-user operating
    systems typically impose memory limits on each process that are much
    smaller than the total amount of memory (virtual or otherwise)
    available on the system.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jan 15, 2007
    #11
  12. Keith Thompson wrote:
    > ...
    > A conforming implementation must support recursion; it's not optional.


    No, it's a QoI issue.

    The implementation shall be able to translate and execute at least
    one
    program that contains at least one instance of every one of the
    following
    limits:
    ...
    - 127 arguments in one function call

    One function call does not recursion make.

    --
    Peter
    Peter Nilsson, Jan 16, 2007
    #12
  13. David T. Ashley wrote:
    > ...
    > As other posters have pointed out, the notion of a "stack" does not
    > appear in the standards.


    No, the word stack does not appear, but the LIFO nature of function
    calling certainly does.

    --
    Peter
    Peter Nilsson, Jan 16, 2007
    #13
  14. "Peter Nilsson" <> writes:
    > Keith Thompson wrote:
    >> ...
    >> A conforming implementation must support recursion; it's not optional.

    >
    > No, it's a QoI issue.
    >
    > The implementation shall be able to translate and execute at least
    > one program that contains at least one instance of every one of
    > the following limits:
    > ...
    > - 127 arguments in one function call
    >
    > One function call does not recursion make.


    Well, yeah, but I think it stretches the point. C99 6.5.2.2p11 says:

    Recursive function calls shall be permitted, both directly and
    indirectly through any chain of other functions.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jan 16, 2007
    #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. Bob Nelson

    doubt about doubt

    Bob Nelson, Jul 28, 2006, in forum: C Programming
    Replies:
    11
    Views:
    624
  2. Casey Hawthorne
    Replies:
    3
    Views:
    1,088
    Flash Gordon
    Nov 1, 2009
  3. Replies:
    0
    Views:
    560
  4. Peter Otten
    Replies:
    2
    Views:
    112
    Cousin Stanley
    Aug 10, 2013
  5. Terry Reedy
    Replies:
    0
    Views:
    115
    Terry Reedy
    Aug 10, 2013
Loading...

Share This Page