What is a stack frame?

[J. J. Farrell]

Recently K. Thompson asked me to specify what did I understand
with "stack frame". I think that it is important for people using the
language, that this important concept is clear, ...

Why? One of the major advantages of using a language like C is that the
programmer doesn't need to know anything about things like stack frames.

 

[Geoff]

Why? One of the major advantages of using a language like C is that the
programmer doesn't need to know anything about things like stack frames.

Huh? What? C insulates you from the machine? Not hardly.

Not understanding how local variables are stored in your
implementation of C leads to problems like buffer overflows and
smashed-stack exploits along with "bad" practices that become
implementation dependent bugs.

Why are strcat, strcpy, gets, scanf, sprintf, sscanf and fopen to name
but a few standard library functions unsafe? If you cannot answer
these questions you should not be programming in C. Go back to your
Java sandbox.

 

[Ian Collins]

Huh? What? C insulates you from the machine? Not hardly.

Not understanding how local variables are stored in your
implementation of C leads to problems like buffer overflows and
smashed-stack exploits along with "bad" practices that become
implementation dependent bugs.

Nonsense.

Not understanding how to use the standard library functions correctly
leads to the above. Whether your implementation stores local variables
on a stack or somewhere else, local storage is still a finite resource.
Where they go isn't important.

 

[Charlton Wilbur]

G> Not understanding how local variables are stored in your
G> implementation of C leads to problems like buffer overflows and
G> smashed-stack exploits along with "bad" practices that become
G> implementation dependent bugs.

Hardly; buffer overflows happen because the programmer creates a
buffer of a certain size and then tries to write past its extents.
This is, in terms of the abstract machine, "undefined behavior." Good
programmers will not write programs that result in undefined behavior.

G> Why are strcat, strcpy, gets, scanf, sprintf, sscanf and fopen
G> to name but a few standard library functions unsafe? If you
G> cannot answer these questions you should not be programming in
G> C. Go back to your Java sandbox.

And the reason they are unsafe is not because of their implementation
but because some of the ways the C abstract machine works mean that
the responsibility for their correct operation has to fall on the
programmer. They are "unsafe" in that using them carelessly will
result in undefined behavior -- which on certain implementations may
include such things as "smashing the stack" and "buffer overruns."

Charlton

 

[Richard Tobin]

Not understanding how local variables are stored in your
implementation of C leads to problems like buffer overflows and
smashed-stack exploits

How?

Just exactly what do you do differently as a result of understanding
how local variables are stored?

-- Richard

 

[Richard]

Nonsense.

Not understanding how to use the standard library functions correctly
leads to the above. Whether your implementation stores local variables
on a stack or somewhere else, local storage is still a finite resource.
Where they go isn't important.

Nonsense.

In the REAL world, understanding how these things work will enable you
to use a real debugger to spot such overflows.

All programmers make mistakes, regardless of how well they know the
standard functions.

 

[Richard Tobin]

[...]

Nonsense.

In the REAL world, understanding how these things work will enable you
to use a real debugger to spot such overflows.[/QUOTE]

Yes, but that wasn't the claim. Understanding the implementation of
local variables may help you *find* this kind of bug, but it's not the
lack of understanding that "leads to" these problems. The mistakes
that cause buffer overflows on the stack are the same ones that cause
buffer overflows elsewhere.

The only reason for mentioning "stack" and "buffer overflow" in the
same breath is that the stack is the easiest place to exploit the
mistake.

-- Richard

 

[Richard]

Not understanding how local variables are stored in your
implementation of C leads to problems like buffer overflows and
smashed-stack exploits along with "bad" practices that become
implementation dependent bugs.

[...]

Nonsense.

In the REAL world, understanding how these things work will enable you
to use a real debugger to spot such overflows.

Yes, but that wasn't the claim. Understanding the implementation of
local variables may help you *find* this kind of bug, but it's not the
lack of understanding that "leads to" these problems. The mistakes
that cause buffer overflows on the stack are the same ones that cause
buffer overflows elsewhere.[/QUOTE]

Agreed. But 99% of systems do indeed use stacks and the "buffer
overflows elsewhere" are simply of no concern to the great majority of C
programmers.

Bottom line is this : learn how stacks work and your debugging skills
will be much better on those architectures with stacks (read just about
all platforms).

 

[Ian Collins]

Not understanding how local variables are stored in your
implementation of C leads to problems like buffer overflows and
smashed-stack exploits along with "bad" practices that become
implementation dependent bugs. [...]

Nonsense.

In the REAL world, understanding how these things work will enable you
to use a real debugger to spot such overflows.

Yes, but that wasn't the claim. Understanding the implementation of
local variables may help you *find* this kind of bug, but it's not the
lack of understanding that "leads to" these problems. The mistakes
that cause buffer overflows on the stack are the same ones that cause
buffer overflows elsewhere.

Agreed. But 99% of systems do indeed use stacks and the "buffer
overflows elsewhere" are simply of no concern to the great majority of C
programmers.

So they don't care if they overflow a dynamic buffer?

Bottom line is this : learn how stacks work and your debugging skills
will be much better on those architectures with stacks (read just about
all platforms).

Knowing how stacks work has little bearing on detecting buffer overflow.
Learning to spot the symptoms of overflowing an automatic variable
does, no matter where they might be allocated.

 

[Richard]

Not understanding how local variables are stored in your
implementation of C leads to problems like buffer overflows and
smashed-stack exploits along with "bad" practices that become
implementation dependent bugs.
[...]

Nonsense.

In the REAL world, understanding how these things work will enable you
to use a real debugger to spot such overflows.
Yes, but that wasn't the claim. Understanding the implementation of
local variables may help you *find* this kind of bug, but it's not the
lack of understanding that "leads to" these problems. The mistakes
that cause buffer overflows on the stack are the same ones that cause
buffer overflows elsewhere.

Agreed. But 99% of systems do indeed use stacks and the "buffer
overflows elsewhere" are simply of no concern to the great majority of C
programmers.

So they don't care if they overflow a dynamic buffer?

Where did I say that?

Knowing how stacks work has little bearing on detecting buffer overflow.
Learning to spot the symptoms of overflowing an automatic variable
does, no matter where they might be allocated.

Symptoms vary a lot. Depending on what the machine is running, the tide
being in or out. Inspecting a stack does not.

 

[Ian Collins]

Where did I say that?

You said: the "buffer overflows elsewhere" are simply of no concern to
the great majority of C programmers.

Symptoms vary a lot. Depending on what the machine is running, the tide
being in or out. Inspecting a stack does not.

Inspecting a automatic storage does not, whether that's a stack is
irrelevant.

 

[Richard]

You said: the "buffer overflows elsewhere" are simply of no concern to
the great majority of C programmers.

Yes. You know I was referring to other stack "replacements". If not, I
apologise for not being clearer.

Inspecting a automatic storage does not, whether that's a stack is
irrelevant.

No it isn't. It's very relevant.

 

[Ian Collins]

No it isn't. It's very relevant.

This is starting to read like a pantomime script.

It my be relevant to you, but it never has been to me.

The End.

 

[Richard]

This is starting to read like a pantomime script.

It is when you gratuitously snip.

It my be relevant to you, but it never has been to me.

The End.

I can only speak for myself. As for "The End", I don't really know quite
who you think you are, but I had hoped for a discussion - not the blinds
pulled down because someone disagrees with your assertions.

 

[Richard Heathfield]

Ian Collins said:

So they don't care if they overflow a dynamic buffer?

Ian, he isn't claiming that. The wording "buffer overflows elsewhere" (i.e.
not on the stack) is Richard Tobin's, and Just Richard is merely quoting
it. He's saying "look, in the real world, buffer overflows happen on the
stack, so let's deal with that".

You might not agree with his overall argument (and neither do I, as it
happens), but there's no need to put words into his mouth. He has not
claimed that people don't care if they overflow a dynamic buffer. In fact,
I think (BICBW) that at the time he said "of no concern" he wasn't
considering dynamic buffers at all, but was referring to buffer overflows
in arcane places, on systems with no stacks.

<snip>

 

[Ian Collins]

Ian Collins said:


Ian, he isn't claiming that. The wording "buffer overflows elsewhere" (i.e.
not on the stack) is Richard Tobin's, and Just Richard is merely quoting
it. He's saying "look, in the real world, buffer overflows happen on the
stack, so let's deal with that".

You might not agree with his overall argument (and neither do I, as it
happens), but there's no need to put words into his mouth.

I didn't, I just misinterpreted what he wrote.

That'll teach me to get into a debate with a resident troll....

 

[Richard]

I didn't, I just misinterpreted what he wrote.

That'll teach me to get into a debate with a resident troll....

So you're the one who gets it wrong and I'm the troll? Laughable.

 

[Richard Heathfield]

Richard said:

So you're the one who gets it wrong and I'm the troll? Laughable.

Trolldom and getting-it-wrongness are not isomorphic. Trolls *deliberately*
post provocative material in the hope of drawing some kind of outraged
reaction. Kenny McCormack and Antoninus Twink are two obvious examples. If
you don't know this already, I'd be very surprised. I think you already
know, too, why Ian Collins considers you a troll. (And yes, I thought so
too, until very recently, when you had the opportunity to be very silly
about a mistake in one of my articles, but clearly made a deliberate
choice not to take that opportunity.)

 

[Antoninus Twink]

Richard said:


Trolldom and getting-it-wrongness are not isomorphic. Trolls *deliberately*
post provocative material in the hope of drawing some kind of outraged
reaction. Kenny McCormack and Antoninus Twink are two obvious examples. If
you don't know this already, I'd be very surprised. I think you already
know, too, why Ian Collins considers you a troll. (And yes, I thought so
too, until very recently, when you had the opportunity to be very silly
about a mistake in one of my articles, but clearly made a deliberate
choice not to take that opportunity.)

You really are the most pompous man it's ever been my misfortune to
encounter.

 

[Kenny McCormack]

On 11 Mar 2008 at 9:16, Sir Richard Heathfield, in his Majesty, graciously
deigned to give of himself in the service of his public, and was heard
to give his assent to the status of, as He so graciously puts it, "Just
Plain Richard", thusly: ....

to which, the good Mr. Twink responded:

You really are the most pompous man it's ever been my misfortune to
encounter.

Yes, I have to agree.