Why are variables stored on the stack?

Discussion in 'C Programming' started by CJ, Mar 14, 2008.

  1. CJ

    CJ Guest

    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?
     
    CJ, Mar 14, 2008
    #1
    1. Advertising

  2. 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.
     
    Harald van Dijk, Mar 14, 2008
    #2
    1. Advertising

  3. CJ

    Flash Gordon Guest

    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.
    --
    Flash Gordon
     
    Flash Gordon, Mar 14, 2008
    #3
  4. CJ

    Willem Guest

    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
     
    Willem, Mar 14, 2008
    #4
  5. CJ

    jacob navia Guest

    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
     
    jacob navia, Mar 14, 2008
    #5
  6. CJ

    santosh Guest

    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.
     
    santosh, Mar 14, 2008
    #6
  7. CJ

    jacob navia Guest

    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
     
    jacob navia, Mar 14, 2008
    #7
  8. CJ

    Ian Collins Guest

    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.
     
    Ian Collins, Mar 14, 2008
    #8
  9. CJ

    jacob navia Guest

    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
     
    jacob navia, Mar 14, 2008
    #9
  10. CJ

    Ian Collins Guest

    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.

    --
    Ian Collins.
     
    Ian Collins, Mar 14, 2008
    #10
  11. CJ

    Eric Sosman Guest

    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.

    --
     
    Eric Sosman, Mar 14, 2008
    #11
  12. 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.
     
    Harald van Dijk, Mar 14, 2008
    #12
  13. 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
     
    Richard Heathfield, Mar 14, 2008
    #13
  14. CJ

    Ian Collins Guest

    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.
     
    Ian Collins, Mar 14, 2008
    #14
  15. CJ

    jacob navia Guest

    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
     
    jacob navia, Mar 14, 2008
    #15
  16. CJ

    santosh Guest

    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.
     
    santosh, Mar 14, 2008
    #16
  17. CJ

    Ian Collins Guest

    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.
     
    Ian Collins, Mar 14, 2008
    #17
  18. >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.
     
    Gordon Burditt, Mar 14, 2008
    #18
  19. In article <e4a3a$47daf246$541dfcd3$1.nb.home.nl>,
    Harald van Dijk <> 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
     
    Richard Tobin, Mar 14, 2008
    #19
  20. In article <>, CJ <> 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
     
    Richard Tobin, Mar 14, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    921
    Mark Rae
    Dec 21, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,073
    Smokey Grindel
    Dec 2, 2006
  3. Casey Hawthorne
    Replies:
    3
    Views:
    1,115
    Flash Gordon
    Nov 1, 2009
  4. Debajit Adhikary
    Replies:
    36
    Views:
    2,348
    Andre Kaufmann
    Feb 10, 2011
  5. Kenneth McDonald

    Why stack overflow with such a small stack?

    Kenneth McDonald, Aug 30, 2007, in forum: Ruby
    Replies:
    7
    Views:
    274
    Kenneth McDonald
    Sep 1, 2007
Loading...

Share This Page