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