zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: [PATCH 3/3] Constify two local variables.
Date: Mon, 30 Nov 2015 16:42:10 +0000	[thread overview]
Message-ID: <20151130164210.56d36bfe@pwslap01u.europe.root.pri> (raw)
In-Reply-To: <20151130155945.GD10968@tarsus.local2>

On Mon, 30 Nov 2015 15:59:45 +0000
Daniel Shahaf <d.s@daniel.shahaf.name> 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 <d.s@daniel.shahaf.name> 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


  parent reply	other threads:[~2015-11-30 16:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-30  3:21 Daniel Shahaf
2015-11-30  9:38 ` Peter Stephenson
2015-11-30 15:59   ` Daniel Shahaf
2015-11-30 16:28     ` Bart Schaefer
2015-11-30 16:42     ` Peter Stephenson [this message]
2015-11-30 20:39       ` Bart Schaefer
2015-11-30 21:36         ` Bart Schaefer
2015-12-02  0:36         ` Daniel Shahaf
2015-12-02  1:11           ` Bart Schaefer
2015-12-03 23:37             ` Daniel Shahaf
2015-12-04  0:36               ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151130164210.56d36bfe@pwslap01u.europe.root.pri \
    --to=p.stephenson@samsung.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).