Debates about the "stack" rage every couple of years on comp.lang.c. Invariably people conflate two different meanings: (1) an abstract data structure with LIFO ordering semantics, and (2) #1 implemented using a contiguous block of [virtual] memory.

The semantics of automatic storage necessarily imply #1, but they do not require #2. Indeed, there are widely used implementations which implement #1 using linked lists (e.g. IBM mainframes, and GCC's split stacks or clang's segmented stacks).

Similarly, function recursion semantics necessarily imply #1 for restoring execution flow, but not #2. In addition to the examples above, so-called shadow stacks are on the horizon which maintain two separate stacks, one for function return addresses and another for data.[1] In the near future a single contiguous stack may be atypical.

[1] Some variations might mix data and return addresses if the compiler can prove safe object access. Or the shadow stack may simply contain checksums or other auxiliary information that can be optionally used, preserving ABI compatibility.

And just going to throw out there that IA64 split the function return stack and data stack into different hardware stacks, so they've been out for twenty years at this point at least.

"C" doesn't just include the spec but also the customary semantics [1] of the language. The customary semantics certainly include the stack and the heap.

[1] https://arcanesentiment.blogspot.com/2014/12/customary-seman...

People don’t learn C by learning the spec, and virtually every c implementation and runtime I know, it uses a stack and heap.

Oddly you seem to recognize this, so I’m not sure what your point is.

At some point, these conversations seem to always turn into a contest to see who can be the most pedantic. Which I think is pretty fun - and pretty well in the spirit of the original article - but that's me, and I can't fault anyone for being turned off by it.

's funny, I am certainly aware of having, at some point, at least skimmed over the C99 standard encountered the concept of a storage duration. But, aside from that brief few hours, virtually the entirety of my C-knowing career has been spent thinking and talking in terms of stacks and heaps.

Meanwhile, in my .NET career, I really did (and, I guess, still do) feel like it was important to keep track of how .NET's distinction is between reference types and value types, and whether or not they were stack or heap allocated was an implementation detail.

Most languages do that internally. It's not a reason you should learn C in particular while you're trying to get an understanding of heaps and stacks.

Indeed. There's a place for language lawyering, but that place is not everywhere.

They just call stack allocation "automatic storage duration" in the spec. If you read it, you pretty much have to implement it as a stack; you just don't have to keep the frames contiguous in memory. They still need to maintain stack style LIFO access though, so the only spec compliant implementations that don't use a traditional stack have back pointers in each frame to maintain stack style LIFO semantics.

I think I only got a reasonable understanding on the stack and heap concepts when I got to make a compiler in my undergrad classes. Some 2 years after I learned C.

I'm not even sure the C memory model depends on the code/stack/heap separation.