C Stack allocation

Discussion in 'C Programming' started by rishu, Jun 10, 2010.

  1. rishu

    rishu Guest

    Hi all,

    was studying the earlier posts regarding the stack and the standards
    associated with it which I must say are none. I mean, In the previous
    posts , it has been remarkedd that there's no concept of stack in C. I
    think that stack / heap allocation is OS's functionality and NOT a
    language's duty to be performed.
    So What i conclude is that C doesnot support stacks BUT MOST of the
    OSs do ... Is it ?
    rishu, Jun 10, 2010
    #1
    1. Advertising

  2. rishu

    Eric Sosman Guest

    On 6/10/2010 10:26 AM, rishu wrote:
    > Hi all,
    >
    > was studying the earlier posts regarding the stack and the standards
    > associated with it which I must say are none. I mean, In the previous
    > posts , it has been remarkedd that there's no concept of stack in C. I
    > think that stack / heap allocation is OS's functionality and NOT a
    > language's duty to be performed.
    > So What i conclude is that C doesnot support stacks BUT MOST of the
    > OSs do ... Is it ?


    This has been debated several times, with (IMHO) more fire
    than light.

    From the C language perspective, we know that function calls
    and returns proceed in a LIFO fashion: The last called is the
    first to return (ignore longjmp() for now). We also know that the
    creation and disappearance of variables and function parameters
    with automatic storage duration proceed similarly: The most recently
    created will disappear before their elder brethren. These LIFO
    disciplines imply "stacks" in an abstract sense: There must be some
    way to "push" and "pop" function activations and auto variables.

    However, the language does not specify any particular technique
    for implementing these abstract "stacks," nor does it specify that
    all LIFO-behaving things reside on the same "stack." As with most
    things, C leaves the implementation to the implementor and refrains
    from dictating particular data structures or particular algorithms.
    A widely-used technique is to set aside a contiguous area of memory
    and move a pointer up and down (or down and up) as things are pushed
    and popped, but this is not the only method. For example, "stack
    frames" might be scattered all over memory and linked together in
    LIFO fashion as the program runs. Function activations might be kept
    on one "stack" while auto variables reside on another and register
    variables on a third. It's up to the implementor to choose a technique
    that fits well on the platform at hand.

    So: We can assume the existence of at least one stack-like data
    structure, but we can't assume much about its/their nature. In
    particular, references to "the stack" are suspect, and questions
    about "which way" "the stack" grows are even more so.

    --
    Eric Sosman
    lid
    Eric Sosman, Jun 10, 2010
    #2
    1. Advertising

  3. rishu

    Tim Harig Guest

    On 2010-06-10, rishu <> wrote:
    > was studying the earlier posts regarding the stack and the standards
    > associated with it which I must say are none. I mean, In the previous
    > posts , it has been remarkedd that there's no concept of stack in C. I
    > think that stack / heap allocation is OS's functionality and NOT a
    > language's duty to be performed.
    > So What i conclude is that C doesnot support stacks BUT MOST of the
    > OSs do ... Is it ?


    C does not provide any stack type; but, it is possible to create a stack
    abstraction using a number of data structures and function wrappers.

    Some OSes (mostly mainframe based) offer system stack and/or queue
    implementations that that user programs can use to store data and which
    persists between processes. These are often used as a form of IPC
    between different routines or processes. The C standard does not offer
    any access to these but a given implementation designed for a such a
    system might as languages for these systems commonly have the ability
    to access these stacks/queues. There are services/daemons available
    from operating systems which do not provide these built in structures.
    For these systems, there will likely be an API available providing
    functions by which C can access these services.

    The stack as often referenced in C, as opposed to a stack or the system
    stack commonly provided on mainframe operating systems, is a common but
    not standardized method for implementing function calls available on
    many hardware architectures (On some embedded systems this is separate
    memory entirely. More conventional systems implement hardware stacks
    in the main memory using a stack pointer). If these are available from
    the given architectural/operating system combination, a C compiler *may*
    choose to implement its function calls using this available structure.
    This is quite common, as it simplifies the code generation, as the
    compiler does not need to implement its own data structures and routines
    for handling function context. There are reasons that a compiler might
    choose not to use the hardware stack, even if it is available, such
    as being able to have an arbitrary length stack, which is useful for
    deeply recursive algorithms, or to help minimize the damage of stack
    based buffer overflow attacks.
    Tim Harig, Jun 10, 2010
    #3
  4. rishu

    rishu Guest

    On Jun 10, 8:29 pm, Richard Heathfield <> wrote:
    > rishu wrote:
    > > Hi all,

    >
    > > was studying the earlier posts regarding the stack and the standards
    > > associated with it which I must say are none. I mean, In the previous
    > > posts , it has been remarkedd that there's no concept of stack in C.

    >
    > More precisely, the C language is defined in such a way that there is no
    > *requirement* for the implementation to use a stack. Typically,
    > implementations very often *do* use hardware stacks (for passing
    > parameter values and for storing local objects), but it's not required
    > and it's not universal.
    >
    > <snip>
    >
    > --
    > Richard Heathfield <http://www.cpax.org.uk>
    > Email: -http://www. +rjh@
    > "Usenet is a strange place" - dmr 29 July 1999
    > Sig line vacant - apply within


    So this means that the broad and diverse concept of memory management
    heaps stacks is not the concern of any programming language . So is it
    the compiler / linker / loader / OS ?
    rishu, Jun 11, 2010
    #4
  5. rishu

    Seebs Guest

    On 2010-06-11, rishu <> wrote:
    > So this means that the broad and diverse concept of memory management
    > heaps stacks is not the concern of any programming language . So is it
    > the compiler / linker / loader / OS ?


    Some combination of the C implementation (which is at least in part involved
    in each of "compiler / linker / loader") and the OS. You could probably
    make a C implementation which used a stack on an OS which didn't, or an OS
    which usually used a stack and a C implementation which didn't use it.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, Jun 11, 2010
    #5
  6. rishu

    Eric Sosman Guest

    On 6/11/2010 9:51 AM, rishu wrote:
    > On Jun 10, 8:29 pm, Richard Heathfield<> wrote:
    >> rishu wrote:
    >>> Hi all,

    >>
    >>> was studying the earlier posts regarding the stack and the standards
    >>> associated with it which I must say are none. I mean, In the previous
    >>> posts , it has been remarkedd that there's no concept of stack in C.

    >>
    >> More precisely, the C language is defined in such a way that there is no
    >> *requirement* for the implementation to use a stack. Typically,
    >> implementations very often *do* use hardware stacks (for passing
    >> parameter values and for storing local objects), but it's not required
    >> and it's not universal.
    >>
    >> <snip>
    >>
    >> --
    >> Richard Heathfield<http://www.cpax.org.uk>
    >> [...]


    Please don't quote signatures: The lines including and after
    the "-- " divider.

    > So this means that the broad and diverse concept of memory management
    > heaps stacks is not the concern of any programming language .


    How do you get from "The C programming language has no explicit
    requirement for a stack" to "No programming language is concerned
    with the broad and diverse concept of memory management?" It
    seems a bit like "That bird is blue, therefore no birds are black."

    > So is it
    > the compiler / linker / loader / OS ?


    If "it" means "the broad and diverse concept," I'm afraid the
    question is too broad and diverse for me. Can you re-frame it in
    more concrete terms?

    --
    Eric Sosman
    lid
    Eric Sosman, Jun 11, 2010
    #6
  7. rishu

    Guest

    Seebs <> wrote:
    >
    > Some combination of the C implementation (which is at least in part involved
    > in each of "compiler / linker / loader") and the OS. You could probably
    > make a C implementation which used a stack on an OS which didn't


    Indeed, the two most popular implementations for the IBM mainframe do
    exactly that.
    --
    Larry Jones

    What's the matter? Don't you trust your own kid?! -- Calvin
    , Jun 11, 2010
    #7
    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. Tom
    Replies:
    9
    Views:
    8,590
    E. Robert Tisdale
    Dec 2, 2003
  2. asm
    Replies:
    3
    Views:
    503
    Michael Str.
    Oct 4, 2003
  3. Ken
    Replies:
    24
    Views:
    3,834
    Ben Bacarisse
    Nov 30, 2006
  4. chris
    Replies:
    6
    Views:
    971
    chris
    Oct 28, 2005
  5. Bjarke Hammersholt Roune
    Replies:
    14
    Views:
    1,167
    Bjarke Hammersholt Roune
    Mar 6, 2011
Loading...

Share This Page