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

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.

 

[Flash Gordon]

CJ wrote, On 14/03/08 20:58:

Hello:

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

Only on implementations which use the stack, although this is probably
the majority. On implementations that don't use a stack such erroneous
programs overwrite something else instead.

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

Because that is one of the things the chip designers provide the stack for.

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

If some other resource is used then that resource can be easily
exhausted as well.

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?

On most implementations with a stack and a heap your suggestion would be
very inefficient.

A better solution would be for the chip designers and manufactures to
provide separate stacks for return addresses and data with the stack for
return addresses being protected.

 

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

It doesn't.

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

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

 

[santosh]

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]

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

 

[Ian Collins]

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.

 

[jacob navia]

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.

 

[Ian Collins]

This is wrong. Most C implementations use the hardware stack

Please stop confusing practical implementation with requirements.

 

[Eric Sosman]

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 "traditional" 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.

 

[Harald van Dijk]

This is blatantly wrong.

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

Most C implementations use the stack.

True and completely irrelevant. C does not insist on storing local
variables on the stack. C does not care where implementations store local
variables.

The original question asked why C prohibited a specific kind of an
unusual implementation. The only correct answer is that it doesn't.

 

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

 

[Ian Collins]

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, while most implementations do use a stack, there can be
those that don't. Whether automatic variables are on a stack or in some
other memory area, that area will be finite and vulnerable to possible
overflows.

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

You as the programmer are free to store your buffers where you choose.
Automatic variables offer the convenience of being automatically created
and cleaned up. Automatic allocation from the heap is possible in other
languages, but comes at a price. On machines with hardware stack
support, moving automatic variables off the stack would degrade
performance without offering any tangible benefits.

 

[jacob navia]

Please stop confusing practical implementation with requirements.

Please stop confusing people by using word games.
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)

 

[santosh]

Please stop confusing people by using word games.
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)

But an important segment of C's usage nowadays is the embedded world.
You simply can't ignore that. And yes, I know that most embedded
systems have a stack too, but I'm sure there are exceptions.

 

[Ian Collins]

Please stop confusing people by using word games.

I'm not, read my reply to the OP and show me where I am "confusing
people by using word games".

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.

It doesn't matter. You, or anyone else, are free to write one without
violating the C standard. Even you can't argue with the plain truth
that C does not insist on storing local variables on a stack. The
standard does not even contain the word "stack".

 

[Gordon Burditt]

We know that C programs are often vulnerable to buffer overflows which

overwrite the stack.

No matter *WHERE* you put variables, you are vulnerable to buffer
overflows.

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

C does not insist on storing local variables on the stack, if there
even is one. Putting them elsewhere (unless it's in ROM) does not
get rid of the buffer overflows. Writable variables, anywhere, are
a security hazard. So, for that matter, is code.

 

[Richard Tobin]

This is blatantly wrong.

[/QUOTE]

Don't lie.

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

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". You could have perfectly well
made it clear with accusing Jacob of lying, which he is obviously not.

-- Richard

 

[Richard Tobin]

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?

That's what the stack is for: storing things that have dynamic scope.

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

They can overflow whatever area they are stored in. If you find
they are overflowing the stack, increase the limit on your stack
size.

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.

A typical C implementation does not store executable code on the
stack. The problem with buffer overflows on the stack is that return
addresses are overwritten. The point of storing local variables on
the heap would be to separate user data from control data, not from
executable code.

A much simpler approach is to make the stack non-executable, so that a
buffer overflow on the stack can't include executable code.
Unfortunately until recently some widely-used processors did not provide
a mechanism for this.

See http://en.wikipedia.org/wiki/Stack_buffer_overflow for more on
this.

-- Richard