From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6005 invoked by alias); 13 Sep 2015 16:47:43 -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: 36530 Received: (qmail 11403 invoked from network); 13 Sep 2015 16:47:43 -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 autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=Kosf6WIEu28hVLFINfNSWiYMm3V2NLt3lADwNw3TuwY=; b=V/hQfAyNMsLST3IPbqfQ6WgkRCjf2uunTjm+F70BsS86EZd1Kc9JaI/Dh3ovcn6EuK cqGnUdR3nHdjj9tOS3W9EKsSG+gQqgpiElZM+ZD8nSsW7eGo7skGrg4sOp7cxdvR3OQ5 4p4hN9PhSKQnJptn9/P1xg8TZO8PushsKeF5zZ2Ze6TXQW7+eZ8EtIoJ8qlgrYPQHRTy k88Dz7xHXlvM1gGjyNICsKGXLwxgGek+TgJf1HKLgf4zgzDjaBDtUgcc/530yJMzIIrN fCK6vIHd8K5cilF+w/FSLrJLMo3zuVNrrmyCZMrb79rR/U7WT0kZCpFOE5EHxx0m1+6U 99Iw== X-Gm-Message-State: ALoCoQnzDeiYlJpSTDhWRXixpC+lV8V2rpFqySSzRGxhEjAABuk9u1EQTlryYp2QAUt5RAoZhR/T X-Received: by 10.60.140.132 with SMTP id rg4mr8055463oeb.70.1442162858429; Sun, 13 Sep 2015 09:47:38 -0700 (PDT) From: Bart Schaefer Message-Id: <150913094735.ZM23422@torch.brasslantern.com> Date: Sun, 13 Sep 2015 09:47:35 -0700 In-Reply-To: Comments: In reply to Sebastian Gniazdowski "Re: Patch for curses module" (Sep 13, 1:58pm) References: <150912090835.ZM11765@torch.brasslantern.com> <150912113349.ZM12036@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Patch for curses module MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 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. } 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. You can try to thwart this by allocating something that is NOT freed every so often, so that there's less chance of a contiguous block for malloc to release, but ultimately trying to control memory layout from the shell script level is never going to produce a consistent result.