[hellfish]

> " ... is often called the stack."

What's wrong about the stack part? It seemed a little odd (and unnecessarily abstract) that the author said "automatic storage" instead of just stack

is there a situation where there's automatic storage but no stack?

[tmewett]

Hah, "unnecessarily abstract" is my middle name :)

I don't really like stack/heap terminology. "Heap" especially is a nightmare because (a) it also means some specific, irrelevant kind of data structure and (b) there's so many ways of implementing allocation it feels wrong to call it "the" anything.

Function variables are deleted after return, allocated stuff isn't - no need to know about stack pointers, etc. It's good enough for me!

But it's really interesting to hear from other programmers who learned things in the historical order. I suppose I come from a new generation where abstractions are first, and I wrote this article for them, really.

[steveklabnik]

The C standard does not use the term "stack," it uses the term "automatic storage duration."

The idea is to separate implementation from semantics.

[lmm]

> is there a situation where there's automatic storage but no stack?

Yes. As a trivial example, some C interpreters use a different datastructure instead of a stack.

[winReInstall]

But the stack refers to the number of calling functions, stacked upon one another too? This is why its always stack, disregard the structure.. cause its a mirror of the program running, and the usual c program uses functions.

[lmm]

Well, the term is overloaded. C has recursion so an implementation needs something like a call stack, but you don't have to store it in a stack datastructure.