From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3245 invoked from network); 4 Dec 1998 18:12:49 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 4 Dec 1998 18:12:49 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id NAA26279; Fri, 4 Dec 1998 13:11:06 -0500 (EST) Resent-Date: Fri, 4 Dec 1998 13:11:06 -0500 (EST) Message-ID: <19981204153950.58656@athenaeum.demon.co.uk> Date: Fri, 4 Dec 1998 15:39:50 +0000 From: Phil Pennock To: zsh-workers@math.gatech.edu Subject: Re: heap memory issues Mail-Followup-To: zsh-workers@math.gatech.edu References: <199812040949.KAA15607@beta.informatik.hu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199812040949.KAA15607@beta.informatik.hu-berlin.de>; from "Sven Wischnowsky" on Fri 4 Dec 1998 (10:49 +0100) Organisation: Organisation? Here? No, over there ----> X-Disclaimer: Any views expressed in this message, where not explicitly attributed otherwise, are mine and mine alone. Such views do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. X-Phase-of-Moon: The Moon is Waning Gibbous (99% of Full) Resent-Message-ID: <"CQPT6.0.VQ6.wM2Qs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4702 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Typing away merrily, Sven Wischnowsky produced the immortal words: > Btw. is the type `long long' in the ANSI-standard? I always thought it > was some special thing offered only by gcc. I've not read the C9X draft. It's big; thinking about it, now is the time to do so. I emailed zefram in January with the URLs: Also in postscript and PDF (according to what I wrote when I mailed him, anyway. Too long ago for me to actually remember). Reading through subsequent email with zef, C9X apparently adopts 'long long' rather than specifiable integer sizes. > Bart already described the meaning of the second argument to > zfree(). To answer the other thing: I don't see a place where a heap > can be allocated that has an arena of less than HEAD_ARENA_SIZE > bytes in which case we simply don't have the problem you > described. Could you enlighten me where this small head arena can be > allocated? If an big hunk was allocated, such that an overly large arena was created for it, then reallocating to a size less than the maximum looked to me as if it would allocate a small arena. I think. I want to leave it a few years before looking at that code again. ;^) -- --> Phil Pennock ; GAT d- s+:+ a22 C++(++++) UL++++/I+++/S+++/H+ P++@ L+++ E-@ W(+) N>++ o !K w--- O>+ M V !PS PE Y+ PGP+ t-- 5++ X+ R !tv b++>+++ DI+ D+ G+ e+ h* r y?