4 ms·

" ... is often called the stack." " integers are cursed" These statements and a few others made me uncomfortable. They imply, to me, that the author has too li

" ... is often called the stack." " integers are cursed" These statements and a few others made me uncomfortable. They imply, to me, that the author has too little knowledge of computer internals to be programming in C. C does a wonderful job of looking like a high level language but it was designed to do low level stuff. There is an implicit assumption, to my mind, that the user has a deeper understanding of what is behind the "curtain" that is created by the compiler. It almost seems like the there should a pre-requisite course like "Introduction to Computer hardware" before one is allowed to write a line of C. Maybe I'm just too old...

pclmulqdq 4y ago
I think the "automatic storage" terminology is technically correct. C can be used in places where there is no actual "stack" and these still need a mechanism for local variables, so they specify a different kind of automatic storage. Everyone uses a stack now, though, even very exotic processors.
- Koshkin 4y ago
  You can easily have a stack without the special machine instructions (like push and pop) or the special stack pointer register. In fact, such special register is only useful in the absence of (a sufficient number of) general-purpose registers, which is characteristic to simpler architectures that have few registers (most of which, too, are specialized); IBM mainframes, for instance, never had the notion of the stack built into the architecture: to allocate a stack frame the program would simply subtract the entire frame's size from the current value in some register and then populate whatever pieces it needs there using the register as the base pointer.
- webstrand 4y ago
  In the standard it's "automatic storage duration" which is one of the three (or four in C11) classes of storage duration.
jjav 4y ago
> There is an implicit assumption, to my mind, that the user has a deeper understanding of what is behind the "curtain" that is created by the compiler. It's also useful to remember that C is from a time when approximately everyone doing programming understood these things because you had to be exposed to lower level details.
tmewett 4y ago
>C does a wonderful job of looking like a high level language but it was designed to do low level stuff. There is an implicit assumption, to my mind, that the user has a deeper understanding of what is behind the "curtain" that is created by the compiler. Lots of people say this, indeed several comments here talk about learning assembly before C being beneficial. I actually think this is not true, today. In its original incarnation C may have mapped closely to instructions, but the details of e.g. x86 are IMO neither necessary nor particularly useful knowledge. Knowing what memory is like and how stuff is laid out is enough. C is not just a super-thin layer to the bare metal. By "integers are cursed," I mean exactly that: C integers are cursed. The arithmetic behaviours that standard C defines for integers are error-prone and in many cases undefined. C is a layer and it has its own behaviour, it doesn't just expose your CPU.
Existenceblinks 4y ago
Year 1 in my university, they started with electron, I was impressed. All to way to diode and how logic gate was made. And then digital circuit design, and you got your one|two's complement from here.
hellfish 4y ago
> " ... 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 4y ago
  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.
  - deleted 4y ago
    [deleted]
- steveklabnik 4y ago
  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 4y ago
  > 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 4y ago
    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.
jesse__ 4y ago
Unsolicited personal opinion/anecdote incoming: As someone who started writing C with very little understanding of how the underlying hardware worked (or, indeed, programming in general), I support and disagree with parts of this comment at the same time. On one hand, I support the notion that programming well (in any language) requires knowledge of hardware architectures. On the other hand, I disagree that people should not be "allowed to write a line of C" before they have that understanding. I started writing C early on in my programming career (having already dropped out of "Introduction to Computer Hardware"), and I'll admit, it was tough. I probably would have had an easier time if I had taken a year to study x86, win32 internals and graphics pipelines. That said, I was interested in learning to program graphics, so that's what I did, and I learned a tremendous amount while doing it. It was probably the long way round, but if the goal was learning, "just doing it" was an effective strategy. What I'm trying to say here is that for people that would drop out of "Introduction to Computer Hardware", learning C is actually an extremely good supplement for learning about underlying hardware architectures because, in the long run, you have no choice if you want to be good at it.
lmm 4y ago
> There is an implicit assumption, to my mind, that the user has a deeper understanding of what is behind the "curtain" that is created by the compiler. With the behaviour of today's C compilers, what benefit would there be to such an understading? It would seem to mainly give the user a lot of ways to shoot themselves in the foot.

pclmulqdq 4y ago

I think the "automatic storage" terminology is technically correct. C can be used in places where there is no actual "stack" and these still need a mechanism for local variables, so they specify a different kind of automatic storage. Everyone uses a stack now, though, even very exotic processors.

Koshkin 4y ago
You can easily have a stack without the special machine instructions (like push and pop) or the special stack pointer register. In fact, such special register is only useful in the absence of (a sufficient number of) general-purpose registers, which is characteristic to simpler architectures that have few registers (most of which, too, are specialized); IBM mainframes, for instance, never had the notion of the stack built into the architecture: to allocate a stack frame the program would simply subtract the entire frame's size from the current value in some register and then populate whatever pieces it needs there using the register as the base pointer.
webstrand 4y ago
In the standard it's "automatic storage duration" which is one of the three (or four in C11) classes of storage duration.

jjav 4y ago

> There is an implicit assumption, to my mind, that the user has a deeper understanding of what is behind the "curtain" that is created by the compiler. It's also useful to remember that C is from a time when approximately everyone doing programming understood these things because you had to be exposed to lower level details.

tmewett 4y ago

>C does a wonderful job of looking like a high level language but it was designed to do low level stuff. There is an implicit assumption, to my mind, that the user has a deeper understanding of what is behind the "curtain" that is created by the compiler. Lots of people say this, indeed several comments here talk about learning assembly before C being beneficial. I actually think this is not true, today. In its original incarnation C may have mapped closely to instructions, but the details of e.g. x86 are IMO neither necessary nor particularly useful knowledge. Knowing what memory is like and how stuff is laid out is enough. C is not just a super-thin layer to the bare metal. By "integers are cursed," I mean exactly that: C integers are cursed. The arithmetic behaviours that standard C defines for integers are error-prone and in many cases undefined. C is a layer and it has its own behaviour, it doesn't just expose your CPU.

Existenceblinks 4y ago

Year 1 in my university, they started with electron, I was impressed. All to way to diode and how logic gate was made. And then digital circuit design, and you got your one|two's complement from here.

hellfish 4y ago

> " ... 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 4y ago
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.
- deleted 4y ago
  [deleted]
steveklabnik 4y ago
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 4y ago
> 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 4y ago
  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.

jesse__ 4y ago

Unsolicited personal opinion/anecdote incoming: As someone who started writing C with very little understanding of how the underlying hardware worked (or, indeed, programming in general), I support and disagree with parts of this comment at the same time. On one hand, I support the notion that programming well (in any language) requires knowledge of hardware architectures. On the other hand, I disagree that people should not be "allowed to write a line of C" before they have that understanding. I started writing C early on in my programming career (having already dropped out of "Introduction to Computer Hardware"), and I'll admit, it was tough. I probably would have had an easier time if I had taken a year to study x86, win32 internals and graphics pipelines. That said, I was interested in learning to program graphics, so that's what I did, and I learned a tremendous amount while doing it. It was probably the long way round, but if the goal was learning, "just doing it" was an effective strategy. What I'm trying to say here is that for people that would drop out of "Introduction to Computer Hardware", learning C is actually an extremely good supplement for learning about underlying hardware architectures because, in the long run, you have no choice if you want to be good at it.

lmm 4y ago

> There is an implicit assumption, to my mind, that the user has a deeper understanding of what is behind the "curtain" that is created by the compiler. With the behaviour of today's C compilers, what benefit would there be to such an understading? It would seem to mainly give the user a lot of ways to shoot themselves in the foot.