Hacker News Reader

Hacker News

Comment by MichaelCrawford | Hacker News Reader

Full thread

MichaelCrawford

Because Linus Torvalds actually believes that userspace processes have "infinite stack".

I swear I'm not making this up.

View on HN

No, you're not making this up. You just didn't understand a word you read, or how it was meant:

The original Torvalds quote in context:

>"When I started the whole design, started doing programming in user space, which I had not done for 15 years, it was like, wow, this is so easy. I don't need to worry about all these things, I have infinite stack, malloc just works. But in the kernel space, you have to worry about locking, you have to worry about security, you have to worry about the hardware.

I often use "Jonathan Swift" as a psuedonym, more recently I have adopted "Durante degli Alighieri".

You're talking about this interview:

http://opendotdotdot.blogspot.com/2014/01/interview-linus-to...

Classic Mac OS applications had 32 kb of stack. Desk Accessories had 8. Much of my effort to fixing Working Software's QuickLetter went towards reducing stack consumption. My predecessor had apparently not read the fine manual.

We spent a lot if money to purchase MacCLint but it overflowed the stack by megabytes and so corrupted the heap. The author wasnt receptive of my advice to remove all its recursion, he asserted rcursion is necessary for compiler-like programs.

Recursive algorithms di not require recursive implementations. The pricedure fir converting recursion to iteration is documented by Robert Sedgewick in "Algorithms".

Really you do have a stack but its not the runtime stack.

In a compiler recursion is typically used for walking Abstract Syntax Trees, and the recursion depth is usually similar to the scope nesting depth. I find it hard to believe that this could add up to megabytes for normal code.

A common problem in QuickLetter before I fixed it was that it had very large local (stack) variables - big arrays and structs. My first fix was to malloc() anything larger than a couple dozen bytes.

MacCLint was a piece of work; I would be unsurprised were it to have local variables that were megabytes in size.

That is I don't know the depth of recursion but I do know that it blew out the 32 kB limit by megabytes.

MacCLint is also the reason why I always use explicit returns in C-like languages. It would crash - which on Mac OS System 7 would drop my box into MacsBug - if I just fell off the end of a void function.

Dave Johnson, the owner of Working Software, had already advised me to use explicit returns because he once used a compiler that generated incorrect machine code if he didn't do so.

Even without buggy tools explicit returns are handy for setting breakpoints. Some debuggers enable you to break just before return even if you fall off the end but not all do.

> MacCLint is also the reason why I always use explicit returns in C-like languages. It would crash - which on Mac OS System 7 would drop my box into MacsBug - if I just fell off the end of a void function.

Isn't falling off a void function the same as returning from it?

Yes.

It comes 'a bit' late, but couldn't you increase stack size by calling SetApplLimit before calling MaxApplZone?

And of course, initially, classic Mac OS didn't have 32kB of stack on original hardware. It didn't even have 32kB available to applications.

I started at WSI about seven months before System 7 was introduced. At the time the documented limit was 32 kB. Yes applications could call SetApplLimit but Desk Accessories could not, QuickLetter's stack was on top of the application's stack. We had no control over that.

I expect the System always ensured that DAs could have 8 kB of stack on top of whatever the application had; that is, app+DA defaulted to 40 kB.

MacCLint was such a skanky program I don't think it would have done it a whole lot of good to increase the stack.

Aha! I didn't get your problems were with a desk accessory.

Reply on news.ycombinator.com