Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Why are variables stored on the stack?

Reply
Thread Tools

Why are variables stored on the stack?

 
 
Eric Sosman
Guest
Posts: n/a
 
      03-14-2008
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 "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.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Harald van Dijk
Guest
Posts: n/a
 
      03-14-2008
On Fri, 14 Mar 2008 22:35:47 +0100, 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.


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.
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      03-14-2008
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
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      03-14-2008
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, 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.

--
Ian Collins.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      03-14-2008
Ian Collins wrote:
> jacob navia 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
>>

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


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      03-14-2008
jacob navia wrote:

> Ian Collins wrote:
>> jacob navia 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
>>>

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


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.

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      03-14-2008
jacob navia wrote:
> Ian Collins wrote:
>> jacob navia 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
>>>

>> Please stop confusing practical implementation with requirements.
>>

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

--
Ian Collins.
 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      03-14-2008
>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.

 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      03-14-2008
In article <e4a3a$47daf246$541dfcd3$(E-Mail Removed)1.nb.ho me.nl>,
Harald van Dijk <(E-Mail Removed)> wrote:

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

>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
--
:wq
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      03-14-2008
In article <(E-Mail Removed)>, CJ <(E-Mail Removed)> wrote:

>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
--
:wq
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Put variables into member variables or function variables? tjumail@gmail.com C++ 9 03-23-2008 04:03 PM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
where are session variables stored on client DC Gringo ASP .Net 7 01-03-2005 07:59 AM
Where are JSP session variables stored? Steve Sobol Java 6 09-05-2004 04:20 PM



Advertisments