C Stack allocation

[rishu]

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 ?

 

[Eric Sosman]

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.

 

[Tim Harig]

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.

 

[rishu]

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 ?

 

[Seebs]

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

 

[Eric Sosman]

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?

 

[lawrence.jones]

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.