From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7360 invoked by alias); 17 Sep 2017 23:15:14 -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: 41721 Received: (qmail 24217 invoked by uid 1010); 17 Sep 2017 23:15:14 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f175.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.192.175):SA:0(-4.2/5.0):. Processed in 3.210347 secs); 17 Sep 2017 23:15:14 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,RCVD_IN_SORBS_SPAM,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=UBjEMwz5rMrYzfJ9icG9Kqb+3OWmRTpWizyzLih13DI=; b=A37oaMXzenA1dBnOR478YYHpIvX8RzJYl2kkjmnAPfIWPKJ6D3j+8ejxq0f4zeAH6t DFFNUrJJOKWE6dygrkDxC9S0PWscy9zczUxAlPUH2ahURfY9NVo7gX8KnEUBSljeO8kc XJs2QbexPIIJOdn45Y3XIoxv+7jWdItriDd2iOdnLsnfhumuX6ls9DPdu0YVltqIXxYC 3D3nX6sI2+boCgU0ft5l1iIvsxZt1CNI3Wcmsd4PAv/ZwjLrcTP5P1s2Taz4tM2NHGAC lptbq8FQCJTpiQ9zyesMG5XHsq4sX+Kt3/EBbQBT91NHl/CzrlwygUwML4HA5aMTMS08 z2zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=UBjEMwz5rMrYzfJ9icG9Kqb+3OWmRTpWizyzLih13DI=; b=mDR2yK6k5G5H+3fPic5zVp4jYxVO6JBJV2nX/xrQznYUWPGU6XO6Xz4fs/Z8SAKvmD omHqHS6lrYfFztS7hX1J6hzAkuOcJNdCF2MlBF3wKOYh3QEaRf4vmrepXnUAz/FTPP4V qE0nwqe2j7f8SLjYv+AkzYAv+xCC6gUghC26QTz4SGL6WXJS7SLpf8bgeil8QizbBAie JbXTdR+yRko91BZuROHHKgTMajzxzjh5mWsagFf+FD9RPi6wm8tAy2896X9CPfhHgWnw HMdHLWZqh5CdPOu3G0bejIPVENTfmNR82P5jRKbrwJqbpjaIKb4eFkx/5a2U6d28zIp1 dzrQ== X-Gm-Message-State: AHPjjUgCFXVz3bjX/cxmJHukWpOUw209tXYKj6JLgWPkS1r6AatNS6nk XEVOoPx3q+b2PF4LH4c= X-Google-Smtp-Source: ADKCNb4k2Kl5S/3XVRD+09KsdG8VcgiPw4DsNbOaIwAMwNKHTG3LZ9xKc8OBTuvmiJUe83V4Au66NQ== X-Received: by 10.101.70.15 with SMTP id v15mr22428304pgq.446.1505690107888; Sun, 17 Sep 2017 16:15:07 -0700 (PDT) From: Bart Schaefer Message-Id: <170917161514.ZM21068@torch.brasslantern.com> Date: Sun, 17 Sep 2017 16:15:14 -0700 In-Reply-To: Comments: In reply to Anssi Palin "Memory leak when working with undefined associative array keys & problems with unset" (Sep 16, 8:57pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Anssi Palin , "zsh-workers@zsh.org " Subject: Re: Memory leak when working with undefined associative array keys & problems with unset MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 16, 8:57pm, Anssi Palin wrote: } } Zsh appears to permanently allocate some memory when just checking } if a key is defined in an associative array. Hmm. This has to do with order of operations. In order to test whether a[0] is (not) set, the calling code needs a "struct pm" object for which it can attempt to retrieve a value and/or check the PM_UNSET flag. For a hash-typed parameter, there's nowhere to temporarily store such an object except in the hashtable itself. The same level of evaluation that tests ${+...} also handles ${...::=...} which also needs that struct to store into, so we can't NOT allocate it, and because all parameter ops are by value rather than by reference we can't wait until after we've assigned to it to add it to the hash (the knowledge that "a[0]" is part of the hash "a" or even that the key is "0", is lost by the time we're ready to do the assignment -- we have only a handle to the object that resides at $a[0]). The naughty bit is approximately here: #0 getparamnode (ht=0x92c3898, nam=0xb7cb7818 "0") at ../../zsh-5.0/Src/params.c:496 #1 0x080baa56 in createparam (name=0xb7cb7818 "0", flags=570425344) at ../../zsh-5.0/Src/params.c:963 #2 0x080bb869 in getarg (str=0xbfee7eb8, inv=0xbfee7ebc, v=0xbfee8130, a2=0, w=0xbfee7ea8, prevcharlen=0xbfee7e9c, nextcharlen=0xbfee7e98) at ../../zsh-5.0/Src/params.c:1417 #3 0x080bcf10 in getindex (pptr=0xbfee7f14, v=0xbfee8130, flags=0) at ../../zsh-5.0/Src/params.c:1851 #4 0x080bd548 in fetchvalue (v=0xbfee8130, pptr=0xbfee8194, bracks=1, flags=0) at ../../zsh-5.0/Src/params.c:2069 #5 0x080e0193 in paramsubst (l=0xb7cb77a8, n=0xb7cb77c0, str=0xbfee8208, qt=0, pf_flags=0, ret_flags=0xbfee836c) at ../../zsh-5.0/Src/subst.c:2418 I think paramsubst() "knows" that it only wants to check set/unset, but that can't be passed down through fetchvalue() so getarg() doesn't know that it shouldn't create the hashtable element. } The second issue I have pertains to special characters in associative } array keys when unsetting them individually: } } $ key='hello * [ world' } $ typeset -A a=("$key" val) } $ unset "a[$key]" } unset: a[hello * [ world]: invalid parameter name Hmm, when examining ${a[$key]} we enter parse_subscript() with $key tokenized, but there's no way to get the tokenized string to reach the same point in the unset builtin (it's either already expanded, or not tokenized). Also ${a[$key]} passes sub=0 to parse_subscript() whereas "unset" always passes sub=1, but I'm uncertain how that may be relevant. This may argue for making unset a keyword ala typeset, but perhaps someone else has a clever approach.