Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn) Newsgroups: net.lang.c Subject: Re: C stack frame sizes Message-ID: <6255@brl-tgr.ARPA> Date: Fri, 30-Nov-84 20:17:20 EST Article-I.D.: brl-tgr.6255 Posted: Fri Nov 30 20:17:20 1984 Date-Received: Sun, 2-Dec-84 05:38:18 EST References: <18092@arizona.UUCP> Distribution: net Organization: Ballistic Research Lab Lines: 18 > Has anyone ever empirically studied the sizes of C stack frames for UNIX > applications? The particular question I have is: How serious would a > 65kbyte maximum frame size be for a 32 bit machine. I have recently had some practical experience with this issue. On the Gould UTX-32 system (and I believe on IBM 370s too), the architecture rather strongly encouraged the C/UNIX implementors to use a relatively small chunk of address space for the run-time stack. The exact amount can be adjusted when one link-edits a binary executable image; using around 24Kb worked well for nearly all UNIX System V utilities. 64Kb would probably suffice for almost all applications; those having trouble most likely could be fixed by changing large "auto" arrays to "static". I have yet to see a practical example where a huge amount of recursion was required; however, if one turned up, it would not be easy to fix. So a SINGLE stack frame limit of 64Kb would certainly not be very troublesome. I imagine someone has written code that needs more, but they have already severely limited their target machine choices.