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?
87  5383 
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.
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
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
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.
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 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.
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 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.
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.
-- Er*********@sun.com
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
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.
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 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 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.
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.
>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.
In article <e4***************************@cache6.tilbu1.nb.ho me.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.
>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
In article <sl*******************@nospam.invalid>, CJ <cj@nospam.comwrote:
>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
"CJ" <cj@nospam.comwrote in message
news:sl*******************@nospam.invalid...
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?
as per the standard, it does not.
as per implementations:
it matches established practice and calling conventions (aka: in 32-bit land
code from one compiler very often links acceptably with that from another);
in the general case, this allows the greatest performance (the stack is
usually a dedicated register into a sliding region of memory, and can thus
be adjusted very quickly).
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.
1. whatever is done, sufficiently deep recursion will break something (be it
a stack overflow or running out of heap).
2. security vulnerabilities will still exist, though they will be mildly
reduced.
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?
simply for partly addressing security issues, a compiler could concievably
treat arrays specially, namely by moving them off the main stack, and
possibly implementing bounds checking (for common cases). if done well, this
could potentially be done with only a minor performance impact. note that
ordinary local variables would likely remain on the stack.
if one does move the locals off the stack (actually, I had considered partly
doing this eventually for the sake of implementing lexical closures), then
they could go "all the way", essentially ending nearly all use of the main
stack (apart from possibly temporary values or similar), which would allow
implementation of many features, such as closures, call/cc, more effective
use of tail-elimination, ...
the big cost would be, for a language like C, this would incur a notable
performance cost (and, very likely, tightly couple the compiled code and the
runtime, making compilation of stand-alone code very problematic).
however, for such a compiler, one "could" possibly make use of a hybrid
approach, using good old stack-frames wherever it can be "proven" that it is
safe to do so (functions are leaf and don't use any advanced features, or
can be verified not use and such features and only call functions with this
same property).
basically, we allow both performance and call/cc, by proving that call/cc,
closures, or anything like them, occur nowhere within the possible call
graph from this point downward (could be very difficult in practice, given
tracability issues, possible use of function pointers, ...).
so, in short, this would be a very expensive feature (but still something I
may pursue at some point, noting that my compiler is primarily JIT-based so
this is acceptable, but likely not so in a more traditional stand-alone
compiler...).
or such...
On Fri, 14 Mar 2008 21:58:57 +0100 (CET), CJ <cj@nospam.comwrote 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.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
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.
On Fri, 14 Mar 2008 23:34:38 +0000, Richard Tobin wrote:
In article <e4***************************@cache6.tilbu1.nb.ho me.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.
"CJ" <cj@nospam.comwrote in message
news:sl*******************@nospam.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."
"Portability 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
jacob navia <ja***@nospam.comwrites:
[...]
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_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"Rod Pemberton" <do*********@nohavenot.cmmwrote in message
news:fr**********@aioe.org...
"CJ" <cj@nospam.comwrote in message
news:sl*******************@nospam.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
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
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.
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>
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.
Thanks for all the replies, this is an interesting discussion.
Here are a couple of points that occur to me:
1) Buffer overflows are a more serious security problem on the stack
than on the heap, because the program counter is stored on the stack and
not the heap, so that a malicious stack overflow can execute arbitrary
code. The heap is used for data exclusively, which is what I meant by
"separate data from executable code".
Even if a buffer on the heap overflows, the worst that can happen is
some (probably insignificant) data corruption. Since malloc() generally
allocates space in powers of 2, often an off-by-one error or similar
won't overwrite anything anyway, but will just land in the gap between
the end of the buffer and the next power of 2.
2) I believe the argument about it being more efficient to use the stack
than the heap is spurious - if I recall, both are O(N) data structures.
CJ said:
Thanks for all the replies, this is an interesting discussion.
Here are a couple of points that occur to me:
1) Buffer overflows are a more serious security problem on the stack
than on the heap, because the program counter is stored on the stack and
not the heap, so that a malicious stack overflow can execute arbitrary
code. The heap is used for data exclusively,
Such as return addresses and function pointers, you mean? Sounds like a
great way for an attacker to execute arbitrary code.
Keep death off the roads - drive on the pavement.
(Or "sidewalk", if you're in the USA.)
Changing the place where an attack happens won't stop the attack happening.
It'll just change the scenery.
--
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
CJ wrote:
Thanks for all the replies, this is an interesting discussion.
Here are a couple of points that occur to me:
1) Buffer overflows are a more serious security problem on the stack
than on the heap, because the program counter is stored on the stack
and not the heap, so that a malicious stack overflow can execute
arbitrary code. The heap is used for data exclusively, which is what I
meant by "separate data from executable code".
Even if a buffer on the heap overflows, the worst that can happen is
some (probably insignificant) data corruption. Since malloc()
generally allocates space in powers of 2, often an off-by-one error or
similar won't overwrite anything anyway, but will just land in the gap
between the end of the buffer and the next power of 2.
2) I believe the argument about it being more efficient to use the
stack than the heap is spurious - if I recall, both are O(N) data
structures.
So? If the "heap" were to be used for all C's auto variables in the
suggested LIFO manner, then it *becomes* the stack. In fact that's how
modern systems operate. The "stack" is simply a defined region of
memory, demarcated by two rather special registers. This still doesn't
prevent malicious code execution.
And overwriting the return address is just one possible way to execute
malicious code.
On Sat, 15 Mar 2008 11:24:30 +0100, CJ wrote:
Thanks for all the replies, this is an interesting discussion.
Here are a couple of points that occur to me:
1) Buffer overflows are a more serious security problem on the stack
than on the heap, because the program counter is stored on the stack and
not the heap, so that a malicious stack overflow can execute arbitrary
code. The heap is used for data exclusively, which is what I meant by
"separate data from executable code".
Actually, some programs do put executable code in malloc'ed storage, and
use equally system-specific tricks to make sure that storage becomes
executable. Look up libffi, for example, if you're interested.
jacob navia said:
Jack Klein wrote:
<snip>
>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.
Who cares?
The OP.
We are speaking about mainstream implementations here.
Well, *you* are. The rest of us are actually addressing the OP's question,
by discussing what the C Standard actually requires. The OP asked "Why
does C insist on storing local variables on the stack in the first
place?", to which the proper answer is that it does not.
I do not expect you to understand this. I wish I did.
--
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 wrote:
jacob navia said:
>Jack Klein wrote:
<snip>
>>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.
Who cares?
The OP.
>We are speaking about mainstream implementations here.
Well, *you* are. The rest of us are actually addressing the OP's
question, by discussing what the C Standard actually requires. The OP
asked "Why does C insist on storing local variables on the stack in
the first place?", to which the proper answer is that it does not.
I do not expect you to understand this. I wish I did.
I can't imagine why jacob is so stuck up on this issue. Yes, we all know
that the majority (perhaps even a vast majority) of C implementations
use a hardware enabled stack. But majority is not all!
And in any case there is no *requirement* in the C standard that auto
variables be allocated on a stack (hardware or not). Yes, their model
strongly suggests using a LIFO structure, but this not, as far as I can
see, absolutely necessary.
Why can't jacob just admit this point, so that we can stop these
periodic redundant discussions? No one is, AFAIK, saying a stack isn't
commonly used, nor that it is not suitable.
"santosh" <sa*********@gmail.comwrote in message
news:fr**********@registered.motzarella.org...
jacob navia wrote:
>Ian Collins wrote:
>>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.
1: I said that no example of a C implementation without a stack has
been
put forward by the regulars.
Hasn't Jack Klein mentioned the 8051 already?
It's quite an achievement to have created a language Standard that works
even on these lowly processors, but surely it would have been better to
split the language into two?
Then the low-level C can go to town on all the features relevant to those
platforms.
And the high-level C can finally be unconstrained.
And if someone really wants to write 8051 code that also runs on the lastest
64-bit processors, or vice-versa, I'm sure there can be a common subset.
I remember using the 8051 (or was it 8031?) and is was a welcome relief to
get back to the Z80, which seemed like a supercomputer in comparison.
--
Bart
Richard wrote:
santosh <sa*********@gmail.comwrites:
>Richard Heathfield wrote:
>>jacob navia said:
Jack Klein wrote:
<snip>
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.
>
Who cares?
The OP.
We are speaking about mainstream implementations here.
Well, *you* are. The rest of us are actually addressing the OP's
question, by discussing what the C Standard actually requires. The
OP asked "Why does C insist on storing local variables on the stack
in the first place?", to which the proper answer is that it does
not.
I do not expect you to understand this. I wish I did.
I can't imagine why jacob is so stuck up on this issue. Yes, we all
know that the majority (perhaps even a vast majority) of C
implementations use a hardware enabled stack. But majority is not
all!
And in any case there is no *requirement* in the C standard that auto
variables be allocated on a stack (hardware or not). Yes, their model
strongly suggests using a LIFO structure, but this not, as far as I
can see, absolutely necessary.
Why can't jacob just admit this point, so that we can stop these
periodic redundant discussions? No one is, AFAIK, saying a stack
isn't commonly used, nor that it is not suitable.
Change the record Santosh. It's important because the concept of a
stack makes explaining C much, much easier. [ ... ]
Exactly which concept in C is explained easier by introducing a stack?
If explaining a stack was critical to explaining C then how come the
Standard doesn't mention a stack at all? After all the very purpose of
the Standard is to explain C.
I think you are confusing debugging C programs (which is facilitated by
a knowledge of machine level details, which includes the stack, if
there is one), with C per se.
Bartc wrote:
>
"santosh" <sa*********@gmail.comwrote in message
news:fr**********@registered.motzarella.org...
>jacob navia wrote:
>>Ian Collins wrote:
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.
1: I said that no example of a C implementation without a stack has
been
put forward by the regulars.
Hasn't Jack Klein mentioned the 8051 already?
It's quite an achievement to have created a language Standard that
works even on these lowly processors, but surely it would have been
better to split the language into two?
Then the low-level C can go to town on all the features relevant to
those platforms.
And the high-level C can finally be unconstrained.
Isn't this what Stroustrup set out to do? :-)
<snip>
santosh <sa*********@gmail.comwrites:
Richard wrote:
>santosh <sa*********@gmail.comwrites:
>>Richard Heathfield wrote:
jacob navia said:
Jack Klein wrote:
<snip>
>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.
>>
>
Who cares?
The OP.
We are speaking about mainstream implementations here.
Well, *you* are. The rest of us are actually addressing the OP's
question, by discussing what the C Standard actually requires. The
OP asked "Why does C insist on storing local variables on the stack
in the first place?", to which the proper answer is that it does
not.
I do not expect you to understand this. I wish I did.
I can't imagine why jacob is so stuck up on this issue. Yes, we all
know that the majority (perhaps even a vast majority) of C
implementations use a hardware enabled stack. But majority is not
all!
And in any case there is no *requirement* in the C standard that auto
variables be allocated on a stack (hardware or not). Yes, their model
strongly suggests using a LIFO structure, but this not, as far as I
can see, absolutely necessary.
Why can't jacob just admit this point, so that we can stop these
periodic redundant discussions? No one is, AFAIK, saying a stack
isn't commonly used, nor that it is not suitable.
Change the record Santosh. It's important because the concept of a
stack makes explaining C much, much easier. [ ... ]
Exactly which concept in C is explained easier by introducing a stack?
Just about everything. I am amazed you have to ask this. You have been
in CLC too long.
If explaining a stack was critical to explaining C then how come the
Standard doesn't mention a stack at all? After all the very purpose of
the Standard is to explain C.
No its not. Its to define C. A not so subtle difference.
>
I think you are confusing debugging C programs (which is facilitated by
a knowledge of machine level details, which includes the stack, if
there is one), with C per se.
No I am not.
Richard wrote:
) santosh <sa*********@gmail.comwrites:
)Exactly which concept in C is explained easier by introducing a stack?
)
) Just about everything. I am amazed you have to ask this. You have been
) in CLC too long.
You're dodging the question.
PS: It may be true that a lot of 'how does it do it' questions are most
easily answered by 'it uses a stack', but for C programming concepts as
such, I see no need.
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
Richard wrote:
santosh <sa*********@gmail.comwrites:
>Richard wrote:
<snip>
>>Change the record Santosh. It's important because the concept of a
stack makes explaining C much, much easier. [ ... ]
Exactly which concept in C is explained easier by introducing a
stack?
Just about everything. [...]
I can't see any aspect of C that needs a stack to be introduced to
explain it. Can you cite a specific example? Function arguments? Return
values? Auto variables? Variadic functions? Recursion?
The concepts of C can be, AFAICS, explained without resorting to
introducing a stack. Obviously, explaining things in deeper detail,
with reference to actual systems and implementations will need an
introduction to a stack at some point.
<snip>
Willem <wi****@stack.nlwrites:
Richard wrote:
) santosh <sa*********@gmail.comwrites:
)Exactly which concept in C is explained easier by introducing a stack?
)
) Just about everything. I am amazed you have to ask this. You have been
) in CLC too long.
You're dodging the question.
PS: It may be true that a lot of 'how does it do it' questions are most
easily answered by 'it uses a stack', but for C programming concepts as
such, I see no need.
Sigh. You just answered it yourself.
>
SaSW, Willem
santosh <sa*********@gmail.comwrites:
Richard wrote:
>santosh <sa*********@gmail.comwrites:
>>Richard wrote:
<snip>
>>>Change the record Santosh. It's important because the concept of a
stack makes explaining C much, much easier. [ ... ]
Exactly which concept in C is explained easier by introducing a
stack?
Just about everything. [...]
I can't see any aspect of C that needs a stack to be introduced to
explain it. Can you cite a specific example? Function arguments? Return
values? Auto variables? Variadic functions? Recursion?
All contribute.
>
The concepts of C can be, AFAICS, explained without resorting to
introducing a stack. Obviously, explaining things in deeper detail,
with reference to actual systems and implementations will need an
introduction to a stack at some point.
Exactly.
But a stack is easy. Introduce it earlier. You guys crack me up. I think
I need a break from the legalese of this NG. You are getting more
ridiculous by the day.
On 15 Mar 2008 at 10:52, Richard wrote:
santosh <sa*********@gmail.comwrites:
>Hasn't Jack Klein mentioned the 8051 already?
Other examples were mentioned in the past including a TI series
processor and something, IIRC, that Dik T. Winter mentioned.
And this is important to C programmers who come here for help who
program 99.9999% of the worlds Computers how?
What is this "help" you speak of? The purpose of CLC is for the regulars
to grandstand and posture and show off their superior knowledge of the
dustier corners of the Standard - helping people is not on the agenda
here.
"CJ" <cj@nospam.comwrote in message
>
2) I believe the argument about it being more efficient to use the stack
than the heap is spurious - if I recall, both are O(N) data structures.
A stack is O(1) to allocate a chunk, and chunk sizes can be variable. O(N)
to fill the chunk with useful data, where N is chunk size.
A heap is O( f(N) ) to allocate a chunk, where f(N) is some complex and
platform dependent function of the number of chunks allocated. Typically it
will be about logarithmic, certainly under N. You can look up broken stick
distributions and the like if you are interested in problems of
fragmentation and how they impact on block search.
A heap is O(N) to fill with useful data, where N is the chunk size.
So you are not really correct, unless chunk size is very large in
comparision to the number of blocks allocated, in which case that term will
dominate.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>On 15 Mar 2008 at 10:52, Richard wrote:
>santosh <sa*********@gmail.comwrites:
>>Hasn't Jack Klein mentioned the 8051 already?
Other examples were mentioned in the past including a TI series
processor and something, IIRC, that Dik T. Winter mentioned.
And this is important to C programmers who come here for help who
program 99.9999% of the worlds Computers how?
What is this "help" you speak of? The purpose of CLC is for the regulars
to grandstand and posture and show off their superior knowledge of the
dustier corners of the Standard - helping people is not on the agenda
here.
So true. So true.
Note that this is true by definition, given how they've defined the
topicality rules.
Richard wrote:
) Willem <wi****@stack.nlwrites:
)
)Richard wrote:
)) santosh <sa*********@gmail.comwrites:
))Exactly which concept in C is explained easier by introducing a stack?
))
)) Just about everything. I am amazed you have to ask this. You have been
)) in CLC too long.
)>
)You're dodging the question.
)>
)PS: It may be true that a lot of 'how does it do it' questions are most
)easily answered by 'it uses a stack', but for C programming concepts as
)such, I see no need.
)
) Sigh. You just answered it yourself.
Were it not that 'how does it do it' is only a small part of the things
you need to explain about C. So 'Just about everything' is quite wrong.
When you are explaining programming, and the student asks 'but how does
the compiler do X', you can also answer 'it doesn't matter'.
Put together, 'it uses a stack' is an answer to precisely those questions
that don't matter.
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 wrote:
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)
I suppose I don't post enough to be considered a "regular".
In Message ID:<47***********************@auth.newsreader.octa news.com>
(Macro that allocates storage and "returns" value) I mentioned that some
embedded processors use static allocation rather than a stack. Besides 1k
coffee machines, it also also used on PICs with 128k code space and a few k
of RAM.
Could a stack be used? Yes, especially for the larger memory processors,
but the instruction set does not provide an efficient means of accessing
stack-based variables, so performance and code size would suffer.
--
Thad
"Richard" <de***@gmail.comwrote in message
news:fr**********@registered.motzarella.org...
santosh <sa*********@gmail.comwrites:
>jacob navia wrote:
>>1: I said that no example of a C implementation without a stack has
been put forward by the regulars.
Hasn't Jack Klein mentioned the 8051 already?
Other examples were mentioned in the past including a TI series
processor and something, IIRC, that Dik T. Winter mentioned.
And this is important to C programmers who come here for help who
program 99.9999% of the worlds Computers how?
Um, you do realize that embedded systems comprise the _vast_ majority of
computers in existence today and that "traditional" computers like you're
used to are a small minority, right?
Just because _you_ don't program 8051s, DSPs, etc. doesn't mean that they're
not important.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: pertheli |
last post by:
I am in a situation where only "goto" seems to be the answer for my
program logic where I have to retry calling some repeated functions.
Can anybody help in the usage of goto and its effect in...
|
by: Andre |
last post by:
Hi,
If I say:
int i = 5;
Does 'i' get stored on the stack? If yes, where *is* the stack? On the
heap? What manages the stack and how does it get created? Thanks
-Andre
|
by: S. A. Hussain |
last post by:
Where Global variables created in STACK or HEAP in C/C++?
ve##tolimitsyahoocom, delete ##
|
by: Murali |
last post by:
Hi
Can anyone tell me where a static variable be stored. I am sure that it is
stored in the data segment of the executable's memory footprint...But in
what? a stack or a heap or is it purely...
|
by: Madhav |
last post by:
Hi all,
I did not understand why do the global vars are
initialized to NULL where as the block level variables have random
values? I know that the C standard requires this as was mentioned in a...
|
by: Clausfor |
last post by:
Hello,
I have a problem with restoring variables in the setjmp/longjmp
functions:
K&R2 for longjmp says:
"Accessible objects have the same value they had when longjmp was
called, except for...
|
by: tshad |
last post by:
Using VS 2003, I am trying to take a class that I created to create new
variable types to handle nulls and track changes to standard variable types.
This is for use with database variables. This...
|
by: kr |
last post by:
Hi All,
Suppose I consider a sample program as given below:-
#include<stdio.h>
#include<stdlib.h>
int i;
int main()
{
char *test(int i);
char *tmp = NULL;
|
by: linyimin |
last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
|
by: kcodez |
last post by:
As a H5 game development enthusiast, I recently wrote a very interesting little game - Toy Claw ((http://claw.kjeek.com/))。Here I will summarize and share the development experience here, and hope it...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Sept 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: Taofi |
last post by:
I try to insert a new record but the error message says the number of query names and destination fields are not the same
This are my field names
ID, Budgeted, Actual, Status and Differences
...
|
by: DJRhino1175 |
last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this -
If...
|
by: Rina0 |
last post by:
I am looking for a Python code to find the longest common subsequence of two strings. I found this blog post that describes the length of longest common subsequence problem and provides a solution in...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: lllomh |
last post by:
How does React native implement an English player?
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
| |
