Zsh Mailing List Archive
Messages sorted by:
Re: One possible answer to typeset vs. unset
- X-seq: zsh-workers 47721
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Felipe Contreras <felipe.contreras@xxxxxxxxx>
- Subject: Re: One possible answer to typeset vs. unset
- Date: Fri, 4 Dec 2020 07:49:54 -0800
- Archived-at: <https://zsh.org/workers/47721>
- Archived-at: <http://www.zsh.org/sympa/arcsearch_id/zsh-workers/2020-12/CAH%2Bw%3D7YxvpfjxCP9i9fHSfu0TWXpiCqXrmLkiVDDiDjZWLC8xQ%40mail.gmail.com>
- Authentication-results: zsh.org; iprev=pass (mail-ot1-f43.google.com) smtp.remote-ip=188.8.131.52; dkim=pass header.d=brasslantern-com.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256; dmarc=none header.from=brasslantern.com; arc=none
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yXIfpMPXiXci/ao7vIO8Z6gXtjdY9foRPWZ8TfmRIu0=; b=OWm0bfycvI1SKFhWhE1W6yFX9SZmZWIfsV5KOZYEyBTScj1bfsmcxqNT8SLYb6DLYr XfwGsb8UV70+pVGJPwMdi9xzX9AleKZcpvSHfFnX2bt7j92AXaXo/enA6Cv6C+V1/1C6 yrNcmVi8dhdOBRSJKMGvLOz6mxb1kw9m2JW4K4dSl+h+EEVl5MVa0qNmojZ2XrrLPDhG 2pITM1iMvYNNGk1IxqSfYnmY6T2/q6D/U50+2Lvh/SNBGWaXTOyuNNb5epTcGhmo5jqB /I00QPIvbt8M4U6Vf7Hxq5ukokgweCh8V9L5MWp0hyZeI/S1vHqAFkhmyzDtw+R1kIPL A3DQ==
- In-reply-to: <CAMP44s3y2zqbG=8Zxqmn5RcwHC-CF2VaiwADhUbj2AokRKndkA@mail.gmail.com>
- List-archive: <http://www.zsh.org/sympa/arc/zsh-workers>
- List-help: <mailto:firstname.lastname@example.org?subject=help>
- List-id: <zsh-workers.zsh.org>
- List-owner: <mailto:email@example.com>
- List-post: <mailto:firstname.lastname@example.org>
- List-subscribe: <mailto:email@example.com?subject=subscribe%20zsh-workers>
- List-unsubscribe: <mailto:firstname.lastname@example.org?subject=unsubscribe%20zsh-workers>
- References: <CAH+w=7Zh8URUiLF2n1x-ZrvKO+=JC8wf+n692sRsFTRbkJrzXw@mail.gmail.com> <CAMP44s2gZnM_JAi78gJwB+uX75Sdx0MQPkW7SZ6tUk85xEjvQg@mail.gmail.com> <CAH+w=7a0es6W_Si9YbQzszzYBSuubmocot_8goywaL_Owbemail@example.com> <CAMP44s3y2zqbG=8Zxqmn5RcwHC-CF2VaiwADhUbj2AokRKndkA@mail.gmail.com>
- Sender: zsh-workers-request@xxxxxxx
On Fri, Dec 4, 2020 at 3:04 AM Felipe Contreras
> On Thu, Dec 3, 2020 at 3:19 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > I looked at this for a while yesterday evening. My conclusion is that
> > tied variables are already a bit of a hack.
Part of my latest commit log on the declarednull branch:
The scalar struct param of a tied pair stores a direct pointer to the
internal array value of the array struct param, and upon assignment
modifies it without referring to the containing struct. This means
that there's no opportunity to clear the PM_DECLAREDNULL bits on both
structs when the scalar is assigned. Conversely, assigning to the
array does use the struct for the scalar.
I think this can be fixed but I don't want it to become inefficient.
OTOH, tied parameters (other than specials, which are different in
several ways) may not be used (or updated when they are) very much.
> > Consequently I don't know if your patch would cause a different test
> > for unset-ness (that hasn't been written yet) to fail, but something
> > like that patch may be unavoidable.
> I can't parse that. What would such unset-ness test do?
Check that both elements of the pair appear to be unset when neither
has been initialized.
As it currently stands on the branch, following
typeset -T TIED_SCALAR tied_array
typeset -p TIED_SCALAR
typeset -p tied_array
print differing initializers.
Messages sorted by: