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 KAA16025 for ; Tue, 25 Jun 1996 10:32:23 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id UAA13967; Mon, 24 Jun 1996 20:22:16 -0400 (EDT) Resent-Date: Mon, 24 Jun 1996 20:22:16 -0400 (EDT) From: "Barton E. Schaefer" Message-Id: <960624172253.ZM2398@zyrcon.z-code.com> Date: Mon, 24 Jun 1996 17:22:52 -0700 In-Reply-To: Zoltan Hidvegi "Re: BUG: useheap in doexpandhist()" (Jun 25, 2:01am) References: <199606250001.CAA06897@bolyai.cs.elte.hu> Reply-To: schaefer@z-code.ncd.com X-Face: #Fj,SD!uGM$mK+=c."{GSa.kjFfFet4[=3Bwr{5@oO*TuJEP3=}'%qRL$bP#~s|yS9JO1v+ &XeZy#u7!sml79&(,L$Q:/2(2?b Subject: Re: BUG: useheap in doexpandhist() Cc: zsh-workers@math.gatech.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"MqA3r1.0.6Q3.t4ppn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1442 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jun 25, 2:01am, Zoltan Hidvegi wrote: } Subject: Re: BUG: useheap in doexpandhist() } } The signal trap can leave the allocation in some undefined state. My } patch just makes sure that after executiong the trap the original } allocation state is restored. Hmm. I understand the part about restoring the original state, but how can the trap leave the allocation in an *undefined* state? Seems to me that if the trap doesn't always *leave* the allocation in the same state (heap, it appears) then there's something more serious wrong. It's the state when you *start* handling the signal that is unknown (to the trap). That means restoring state is the right thing to do regardless of other reentrancy issues; but maybe it's doshfunc() that should be saving and restoring the state, so that it's consistent everywhere doshfunc() is called? } I think that the heap used in zsh is very useful. It is convinient, it } certainly guarantees that there is no memory leak if the heap is used and } it is efficient since instead of calling malloc()/free() frequently we call } these only a few times. Yes, the heap certainly guarantees that zsh's performance will be just about the same no matter how well or poorly the underlying malloc works. It also guarantees that if you accidentally allocate something on the zsh heap that should have been on the "permanent" heap, zsh eventually will dump core; and it almost guarantees that programmers will be sloppy about freeing memory, because they assume the heap prevents leakage. I apologize to members of the Paul Falstad Fan Club, but I think zsh would have been a lot more reliable a whole lot sooner if he had never used that trick. -- Bart Schaefer Vice President, Technology, Z-Code Software schaefer@z-code.com Division of NetManage Corporation http://www.well.com/www/barts http://www.ncdsoft.com/ZMail/