Why are variables stored on the stack?

[CJ]

Hello:

We know that C programs are often vulnerable to buffer overflows which
overwrite the stack.

But my question is: Why does C insist on storing local variables on the
stack in the first place?

I can see two definite disadvantages with this:
1) deeply nested recursive calls to a function (especially if it defines
large local arrays) can easily overflow the stack
2) the problems described above of security vulnerabilities .

My solution would be for C instead to store its local variables on the
heap - effectively separating data from executable code.

What do people think?

[Jack Klein]

On Fri, 14 Mar 2008 21:58:57 +0100 (CET), CJ <[e-mail] rote in
comp.lang.c:

Hello:

We know that C programs are often vulnerable to buffer overflows which
overwrite the stack.

Not on most C compilers for 8051 architecture.

But my question is: Why does C insist on storing local variables on the
stack in the first place?

As has been said to death, C does not. Quite a few C compilers
specifically do not. I know of at least one architecture where it is
quite impossible, as the stack is completely inaccessible to
instructions other than call and return.

I can see two definite disadvantages with this:
1) deeply nested recursive calls to a function (especially if it defines
large local arrays) can easily overflow the stack
2) the problems described above of security vulnerabilities .

My solution would be for C instead to store its local variables on the
heap - effectively separating data from executable code.

What do people think?

I think I can see two definite disadvantages with people pontificating
about subjects in which they have insufficient. Deducing what they
are is left as an exercise to the reader.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Kenny McCormack]

In article <fr***********@ pc-news.cogsci.ed. ac.uk>,
Richard Tobin <ri*****@cogsci .ed.ac.ukwrote:
....

>The C standard does not insist on a stack. Almost all implementations
do. The OP is unlikely to know that some people here will insist on
interpreting "C" as "the C standard". You could have perfectly well
made it clear with accusing Jacob of lying, which he is obviously not.

Oh oh. Clique membership in jeopardy.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Fri, 14 Mar 2008 23:34:38 +0000, Richard Tobin wrote:

In article <e4************ *************** @cache6.tilbu1. nb.home.nl>,
Harald van Dijk <tr*****@gmail. comwrote:

>>>>But my question is: Why does C insist on storing local variables on
the stack in the first place?

>>>It doesn't.

>>This is blatantly wrong.

>>Don't lie.

You don't have to drag your endless dispute with Jacob into *every*
thread.

Excuse me? You might want to re-read the thread. I didn't drag anything
in here.

>>C doesn't insist on a stack, and you know it just as well as most others
here.

The C standard does not insist on a stack. Almost all implementations
do. The OP is unlikely to know that some people here will insist on
interpreting "C" as "the C standard".

The OP ("CJ", as should have been mentioned in the attributions) is no
stranger here, and has asked questions why things are or aren't in the
standard in the past here in c.l.c. I was pretty sure that's what he's
asking now.

You could have perfectly well
made it clear with accusing Jacob of lying,

Yes, and I should have, but...

which he is obviously not.

....I'm not convinced one way or the other. However, jacob, I do apologise.

[Rod Pemberton]

"CJ" <[e-mail] rote in message
news:sl******** ***********@nos pam.invalid...

But my question is: Why does C insist on storing local variables on the
stack in the first place?

I think the following is more informative than all the other responses
you've gotten so far:

"Any function in C may be recursive (without special declaration) and most
possess several 'automatic' variables local to each invocation. These
characteristics suggest strongly that a stack must be used to store the
automatic variables, caller's return point, and saved registers local to
each function; in turn, the attractiveness of an implementation will depend
heavily on the ease with which a stack can be maintained."

"Portabilit y of C Programs and the UNIX System" SC Johnson and DM Ritchie
http://cm.bell-labs.com/cm/cs/who/dmr/portpap.html
Rod Pemberton

[Keith Thompson]

jacob navia <ja***@nospam.c omwrites:
[...]

I have yet to see a SINGLE example of an implementation that
doesn't use a stack for the local variables. Yes, a single
one.

Until now, there wasn't any that the regulars could put forward.

(Obviously in machines running now, and having a certain
minimum size. Coffee machines with less than 1K of
RAM and similars do not count)

For the umpteenth time, it depends on what you mean by "stack". If
you mean an abstract last-in first-out data structure, then the
semantics of C function calls require a stack (but it's clear that
that's not what the original poster in this thread was referring to).
If you mean a typical contiguous hardware stack managed via a stack
pointer, at least one example of an implementation that *doesn't* use
such a thing has been mentioned here many times, namely an IBM
mainframe system that allocates function activation records on the
heap (or something similar).

--
Keith Thompson (The_Other_Keit h) <ks***@mib.or g>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Malcolm McLean]

"Rod Pemberton" <do*********@no havenot.cmmwrot e in message
news:fr******** **@aioe.org...

"CJ" <[e-mail] rote in message
news:sl******** ***********@nos pam.invalid...

>But my question is: Why does C insist on storing local variables on the
stack in the first place?

I think the following is more informative than all the other responses
you've gotten so far:

"Any function in C may be recursive (without special declaration) and most
possess several 'automatic' variables local to each invocation. These
characteristics suggest strongly that a stack must be used to store the
automatic variables, caller's return point, and saved registers local to
each function; in turn, the attractiveness of an implementation will
depend
heavily on the ease with which a stack can be maintained."

And if a function is recursive there's often no easy way of protecting the
top of the stack from overflow, because the depth of recursion tends to be
controlled by the input.
However a stack overflow is less likely than a buffer overrun into the stack
to be exploitable. When user can overwrite a return address and put
user-defiined bytes that the place the new return points to then you've got
either a security hole or the mother of all user-configurable programs.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Willem]

jacob wrote:
) Willem wrote:
)CJ wrote:
)) But my question is: Why does C insist on storing local variables on the
)) stack in the first place?
)>
)It doesn't. Your question is moot.
)>
)>
)SaSW, Willem
)
) This is wrong. Most C implementations use the hardware stack

It is perfectly correct. You should update your reading skills.
C does not ***INSIST*** on storing local variables on the stack.

'Insist' is something that can be said of requirements and/or standards.
It is *not* something you say of an *implementation *.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[santosh]

Willem wrote:

jacob wrote:
) Willem wrote:
)CJ wrote:
)) But my question is: Why does C insist on storing local variables
on the )) stack in the first place?
)>
)It doesn't. Your question is moot.
)>
)>
)SaSW, Willem
)
) This is wrong. Most C implementations use the hardware stack

It is perfectly correct. You should update your reading skills.
C does not ***INSIST*** on storing local variables on the stack.

C does insist that automatic variables be treated in LIFO manner with
regard to their lifetimes. However this LIFO characteristic needn't be
implemented with a LIFO data structure, I think.

'Insist' is something that can be said of requirements and/or
standards. It is *not* something you say of an *implementation *.

A non-conforming implementation can insist on doing things it's own way.

[santosh]

Willem wrote:

santosh wrote:
) C does insist that automatic variables be treated in LIFO manner
with ) regard to their lifetimes. However this LIFO characteristic
needn't be ) implemented with a LIFO data structure, I think.

You can store all automatic variables in a malloc()ed block, and store
the pointer to that on the stack, for example.

You could also have one stack for call/return, and one for automatic
storage, but the OP's wording 'using _the_ stack' rules this out.

Actually I was wondering if a conforming C implementation could be
written, and a conforming C program compiled and run, without *any* use
of a LIFO data type.

<agree with the rest>

[Ian Collins]

jacob navia wrote:

>
Please look it up and stop telling stories.

Please look up the word "stack" in the standard and tell us where it occurs.

--
Ian Collins.