From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10087 invoked by alias); 13 Sep 2015 19:35:28 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 36531 Received: (qmail 19910 invoked from network); 13 Sep 2015 19:35:26 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=qrcQcseq2gBlrUOzsmEAx7ABbIdUxjyYL+x7N4vXJFk=; b=iaEMhfRzH6F5lCyg+7t7waOtThm1H9bL0jpdjN9zhJ/xZvrvYGJ3WjogZHa0NN+X8d dLORitwXHsZDsr4mGtWWjnJRXYbUZhhsY995gKDCqEqunaOGJVU1ta0wLFX8Lm1P0ouC lbMg/RTmdgpk6YdzZu8IRFU5ronRQxbzKOUH20eHf24/fEh6SswX/pTkc6m2uo1p9liJ TJBgQsMuLUaXNMnHYpw0nEUtM26R8ZK/4Wf63n+qXTepaX2HARQ6Jz0P/71UxOemd1ZB xe3JYMn67/lSnAs0KOLf8A1TELafXoRqKbnphWg0lmoyPHtnP7TE0uPuKGzDMreavgTh SNBw== X-Received: by 10.152.2.227 with SMTP id 3mr10006477lax.54.1442172921945; Sun, 13 Sep 2015 12:35:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <150913094735.ZM23422@torch.brasslantern.com> References: <150912090835.ZM11765@torch.brasslantern.com> <150912113349.ZM12036@torch.brasslantern.com> <150913094735.ZM23422@torch.brasslantern.com> From: Sebastian Gniazdowski Date: Sun, 13 Sep 2015 21:35:02 +0200 Message-ID: Subject: Re: Patch for curses module To: zsh-workers@zsh.org Content-Type: text/plain; charset=UTF-8 On 13 September 2015 at 18:47, Bart Schaefer wrote: > On Sep 13, 1:58pm, Sebastian Gniazdowski wrote: > } > } _provide_clean_memory_to_old_zsh() { > } local i=100 > } while (( i-- )); do > } local a b > } a=" " > } b=" " > } unset a b > } done > } } > > If malloc works the way you think, that loop is just going to allocate > and free the same two blocks over and over. Declaring "local" inside a > loop doesn't have any special meaning. You would at least need e.g. > > while (( i-- )); do > local a$i=" " b$i=" " > done Maybe local means that the memory comes from stack, while zalloc() works on heap? I tried with global variables but still no luck though. > Then because declared local, all the a$i and b$i will be freed at the end > of the function scope, you don't need an explicit unset. > > } Hash node which is part of colorpairnode as: > } struct hashnode { > } HashNode next; /* next in hash chain */ > } char *nam; /* hash key */ > } int flags; /* various flags */ > } }; > > Yes, but you need to clear single blocks the size of the entire > colorpairnode struct (18+ bytes, a hashnode plus a short) rather > than just the size of the prefix hashnode. I have printed sizeof of the struct and it's 16, and 32 on 64 bit machine. > } Therefore filling a 16/32 byte area with zeros or e.g. spaces and then > } freeing it should provide proper memory for zcurses. But this doesn't > } happen. Does unset free memory? What can be done to allocate and free > } 16/32 bytes block? > > Even if you get the size right, the malloc library isn't guaranteed to > re-use freed memory in LIFO order. It may (re)use it in the order > that it can access it the fastest, whether or not that's best-fit. > It might also aggressively release freed blocks back to the OS, in > which case any value you write there may be clobbered by another > thread even if you do get back the same block you previously freed. Yes it's hard to say about guarantees with such trick, good that it's only about colors and older zsh versions. Best regards, Sebastian Gniazdowski