Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!ucsd!ogccse!blake!milton!maven!8610681 From: 8610681@maven.u.washington.edu Newsgroups: comp.sys.amiga Subject: Re: Is she c:Stack'd Message-ID: <7855@maven.u.washington.edu> Date: 3 Oct 89 18:32:40 GMT References: <3944@m2-net.UUCP> <8053@cbmvax.UUCP> <19086@ut-emx.UUCP> Organization: University of Washington, Seattle WA Lines: 42 In article <19086@ut-emx.UUCP>, sjk@ut-emx.UUCP (bob) writes: > Dave Haynie writes: >> in article <3944@m2-net.UUCP>, ba@m2-net.UUCP (Bill Allen) says: >> >> > > What causes certain prgs to work just fine in 4K of stack > > (or less) while others need 10K? I've seen several that > > require 20K, 30K, 40K. Can other programming techniques be > > used to prevent this? > >> The difference usually amounts to something like this: >> [exampes deleted] > > Dave, you're probably right, the average programmer probably does > not know how much stack he is using, or even wonder, perhaps. So > what constructs are there that require stack use? I am a novice > C programmer and while I am capable of writing some relatively > complex code, I don't yet know enough about the internal operations > to know what structures use how much stack and why. While it's certainly good for programmers to have knowledge of the specifics of a machine, and understanding stack usage is a legitimate exercise, it does seem rather silly to force applications to be written quite differently on one machine than another. If I want to write code like: int routine() { int big_space_waster[100000]; { whatever} } I should be able to. Now, it seems that on a non-virtual memory machine (or any machine with a fixed stack space), that the compiler ought to be able to optimize such large requests for local stack into a malloc() on entry and free() on return itself. I should not be have to concerned with such implementation details. Perhaps a flag on the compilation line would dictate whether this behaviour was appropriate and what size of memory to start doing this at. Cheers, Joe Meadows joe@fhcrcvax.bitnet