From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21770 invoked by alias); 30 Nov 2015 16:42:27 -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: 37259 Received: (qmail 19145 invoked from network); 30 Nov 2015 16:42:23 -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-AuditID: cbfec7f4-f79026d00000418a-c2-565c7c65f3ca Date: Mon, 30 Nov 2015 16:42:10 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: [PATCH 3/3] Constify two local variables. Message-id: <20151130164210.56d36bfe@pwslap01u.europe.root.pri> In-reply-to: <20151130155945.GD10968@tarsus.local2> References: <20151130032153.GH2504@tarsus.local2> <20151130093832.5321126d@pwslap01u.europe.root.pri> <20151130155945.GD10968@tarsus.local2> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsVy+t/xy7qpNTFhBqfnyVocbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujF+LQwtucFVseLyUrYHxOEcXIyeHhICJxMOzM9kgbDGJC/fW A9lcHEICSxklVh+dxArhzGCSuP68Dco5xyjx7tYsJgjnLKNE4/u1TCD9LAKqEn3T7rKC2GwC hhJTN81mBLFFBMQlzq49zwJiCwuYSRxsWcoOYvMK2EscnDUbrJ5TwFhi6u0dUEMnMEqcff0a rIhfQF/i6t9PTBAH2kvMvHKGEaJZUOLH5HtgQ5kFtCQ2b2tihbDlJTavecsMYgsJqEvcuLub fQKj8CwkLbOQtMxC0rKAkXkVo2hqaXJBcVJ6rqFecWJucWleul5yfu4mRkhAf9nBuPiY1SFG AQ5GJR5eCbPoMCHWxLLiytxDjBIczEoivLtzY8KEeFMSK6tSi/Lji0pzUosPMUpzsCiJ887d 9T5ESCA9sSQ1OzW1ILUIJsvEwSnVwLhE0GDPvaRfU7c1vt+Ua6n2cPHbOqbukjusAcLsU5m2 3/dPePBHdUXm+r16B+9NMXz94bOkVVhgkfRTTzeX5xyrJMrXLhJv3P/naWdEsVyn7+qg8s+T volGJm+ZuXujMnvc9aVBfHHXl7s3uLoJfxDaWrrWVdrYUt1w6YI+jrWq8Ytfura52yixFGck GmoxFxUnAgAbhKLPZAIAAA== On Mon, 30 Nov 2015 15:59:45 +0000 Daniel Shahaf wrote: > Peter Stephenson wrote on Mon, Nov 30, 2015 at 09:38:32 +0000: > > On Mon, 30 Nov 2015 03:21:53 +0000 > > Daniel Shahaf wrote: > > > I assume that v->pm->gsu.a->getfn() has no access to v->start and > > > v->end, hence changing the order is safe. > > > > Yes, the getfn() is very low level, dealing only with storage for that > > parameter and having no knowledge at all of any expansion/substitution > > happening above it. > > > > Thanks, that's what I expected. What are the lifetime interfaces of > getfn/setfn of arrays? That's less well defined than it should be, but the implication is obviously they will be used within the liftime of the current heap. This is common in e.g. Src/Modules/parameter.c for returning parameters reflecting some internal state. Making sure this is what happens isn't easy. The only real difference from any other use of the heap is that the source of the heap allocation is quite well buried. But maybe that's not much of a difference, since there's much heap allocation a few layers above in paramsubst(). As Bart says, setfn() expects a permanently allocated values; if it doesn't neeed it, it's up to the setfn in question to convert the value and then free what's passed in. pws