From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id FAA05168 for ; Mon, 1 Jul 1996 05:29:49 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id PAA28691; Sun, 30 Jun 1996 15:20:53 -0400 (EDT) Resent-Date: Sun, 30 Jun 1996 15:20:53 -0400 (EDT) From: "Bart Schaefer" Message-Id: <960630122142.ZM11441@candle.brasslantern.com> Date: Sun, 30 Jun 1996 12:21:39 -0700 In-Reply-To: Zoltan Hidvegi "Re: bug (?) in 3.0-pre1" (Jun 30, 6:13pm) References: <199606301613.SAA01458@hzoli.ppp.cs.elte.hu> Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.607 07jun96) To: Zoltan Hidvegi , zsh-workers@math.gatech.edu Subject: Re: bug (?) in 3.0-pre1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"e1Jpt2.0.D07.KEjrn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1489 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jun 30, 6:13pm, Zoltan Hidvegi wrote: } Subject: Re: bug (?) in 3.0-pre1 } } > Seems like almost any of the MUSTUSEHEAP() functions should adjust and } > then restore the allocation strategy internally, rather than relying on } > every caller to do so ... } } But usually it is a bug if the caller use permanent allocation. In most } places zsh uses heap allocation. It is an exception when a function uses } permanent allocation and in that case it must always be very careful. That's true, but it's at odds with the code-structure model implied by the heapalloc()/permalloc()/lastalloc() conventions. A function that calls permalloc() should be able to expect the allocation strategy to remain "permanent" locally to that function, regardless of other calls it may make, up until one of heapalloc() or lastalloc() is called. Similarly, a function that *knows* it needs the heap should be both able to call and responsible for calling heapalloc() without worrying what strategy its caller was using. That's why lastalloc() exists; the only problem with lastalloc() is that it's a toggle rather than a stack. } I know that you do not like this heap very much but I still think that } it simplifies the code and makes memory management faster. It's not the heap itself I object to. What I don't like is that the allocation strategy (heap or "permanent") at any given point in the code is *implicit* rather than *explicit*. Because the strategy is changed globally whenever it changes, a function calling e.g. heapalloc() can't be sure that some other function down the call tree won't permalloc(), thus messing up the allocation strategy expected by the caller. If every function that ever calls heapalloc() or permalloc() were forced to also restore the previous allocation strategy before returning, much of this potential confusion would go away. By the way, I applied your patch from a couple of messages back on this thread, and yet I *still* get: zagzig[83] cd .. BUG: permanent allocation in doshfunc How many of these are you going to track down before you give up and make doshfunc() set up heap allocation on its own? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern New male in /home/schaefer: >N 2 Justin William Schaefer Sat May 11 03:43 53/4040 "Happy Birthday"