In the beginning, there was no way to expand C's stack size

October 20, 2021

There are undoubtedly many reasons that C doesn't have any language or API concept of your stack size. But I think that one factor in this is that in C's original world, that of Unix on the PDP-11, running out of stack size was essentially fatal no matter what you did. The fundamental problem was that there was no way to actually expand the space available for your stack.

Normal programs on the PDP-11 had a 16-bit address space, giving them at most 64 Kb of address space for all of their data, including the stack. Unix on the PDP-11 adopted a simple memory model for this address space; your data went at the bottom followed by the start of the heap, your stack went at the top, and then your heap and your stack grew toward each other without limit (V7 Unix didn't have any kernel limits on your stack size). If you ran out of stack space, it meant that between your stack and your heap you'd used all 64 Kb of available address space. You couldn't reallocate a bigger stack or move memory around or anything; you were plain out of address space. The only way of solving this was to have a smaller heap or a smaller stack.

C on V7 Unix on the PDP-11 was a relatively minimal language used for a minimal operating system on a comparatively slow and limited machine. A careful MIT approach system might still have stack size probes on function entry so that it could give better diagnostics in the unlikely event that you ran out of stack space. C on V7 did not, and this propagated through into the C culture as part of C as a 'portable assembly', one that did very little more than what you explicitly programmed yourself.

(In V7, you did get an error return if you ran out of heap space by trying to grow the heap into the stack (cf). This was possible because growing the heap required an explicit system call, while the stack grew implicitly through usage.)

Sidebar: The general cultural issue

I am not Hillel Wayne so I haven't researched this, but my impression is that very few 1960s and 1970s languages of any sort had any explicit API for the stack and stack sizes, and this was especially the case for languages intended for low level programming. Even today there are generally few languages with any sort of explicit API for things like 'how much stack space am I using', 'what is my stack space limit', and especially 'how much stack space will calling this thing use'. The stack is much more magic than the heap and most everyone continues to pretend that it will always just work.

(C was not the only low level language from the 1960s and 70s, merely the only one that thrived and is well known today. See, for example, BLISS.)

Written on 20 October 2021.
« VCS history versus large open source development
The easy way to see underneath NFS mount points on Linux »

Page tools: View Source.
Search:
Login: Password:

Last modified: Wed Oct 20 22:22:48 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.