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?

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

On Fri, 14 Mar 2008 21:58:57 +0100, CJ wrote:

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?

It doesn't.

[Willem]

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

[jacob navia]

Harald van Dijk wrote:

On Fri, 14 Mar 2008 21:58:57 +0100, CJ wrote:

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

It doesn't.

This is blatantly wrong. Most C implementations use the stack.

This is just nonsense, from the regular regulars...

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[santosh]

CJ wrote:

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?

It doesn't A hardware stack isn't necessary to implement C as defined by
it's standard. It just makes sense in a whole lot of systems where
there is native stack support. It's also easier on the compiler.

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?

All computing resources are finite. The problem is not running out of
resources (which can always happen and for which there is no possible
solution), but in protecting programs from each other, so that a faulty
program, or module can at most destroy itself.

WRT what you say above, no, on system that support maintaining a
hardware stack, there is absolutely no sense in not using it,
particularly for languages like C and C++. The memory protection
enabled by the system will have equal effect, whether it's the stack or
the heap that is involved in overflow. Not using the hardware support
for stacks would impact performance considerably.

It would also complicate compilers that will have to maintain a software
stack anyway for implementing automatic objects.

The whole scheme gives up a lot for almost no real gain. Not in C.

[jacob navia]

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

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Ian Collins]

jacob navia wrote:

Harald van Dijk wrote:

>On Fri, 14 Mar 2008 21:58:57 +0100, CJ wrote:

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

It doesn't.

This is blatantly wrong. Most C implementations use the stack.

The question was "Why does C *insist* on storing local variables on the
stack in the first place?"

It doesn't. If it does, show us the relevant section in the standard.

The fact that most implementation do use a stack, doesn't make it a
requirement.

--
Ian Collins.

[jacob navia]

CJ wrote:

Hello:

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

Only if you can execute code in the stack

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

The principal reason is efficiency. Stack allocation is very fast,
in most cases just a single machine instruction. Deallocation is equally
fast, with a single instruction.

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

Yes, that is why stack allocation of large arrays is not a very
good idea.

2) the problems described above of security vulnerabilities .

This happens only if you have the buffer overflow in the first place.

Note that a buffer overflow of a heap allocated buffer is very
bad also.

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

Yes, that is "a" solution. You can implement this easily in C
if you just instead of

int fn(void)
{
char buffer[BUFSIZ];

}

you write

int fn(void)
{
char *buffer = malloc(BUFSIZ);
}

What do people think?

I think that you should allocate variables as you think is the best for
your application.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Eric Sosman]

CJ wrote:

Hello:

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

Rather, we know that some people who write C are sloppy.
(The same could be said about every programming language I've
ever seen, although the consequences of sloppiness may be
less severe in languages that feature training wheels.)

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

C does not insist on any such thing. However, the use of
one or more stacks is a convenient way to implement the LIFO
lifetimes (LIFOtimes?) of variables with automatic storage
duration.

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.

On most implementations , even on the "traditiona l" stack
implementations you describe, data and code are separated
already and your suggestion wouldn't change that. (The fact
that you think it would makes me suspect you misunderstand the
nature of the problem.)

Two observations about allocating auto storage on "the
heap" (another thing C doesn't insist on, by the way). First,
moving the buffer from one place to another doesn't prevent
overflow, it just alters what's likely to be victimized if
an overflow occurs. Can a program be made to do something
unexpected if a flag mysteriously flips from false to true?

Second, if "the heap" is the area managed by malloc() et
al., it's going to be considerably more expensive to enter
and leave a function (more generally, a block) than with
stack-oriented methods. The auto allocator will be tricky,
too, since its own auto variables would need to be obtained
by some arrangement unlike what ordinary functions use, and
it must be careful about calling ordinary functions lest it
cause an infinite recursion.

--
Er*********@sun .com

[Richard Heathfield]

CJ said:

Hello:

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

More precisely, we know that some C programmers sometimes allow too much
data to be written into buffers.

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

C imposes no such requirement. It's up to the implementation.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999