From: Bart Schaefer <schaefer@brasslantern.com>
To: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: [PATCH] declarednull: rename DECLARED to NULL
Date: Thu, 7 Jan 2021 14:29:38 -0800 [thread overview]
Message-ID: <CAH+w=7a8YBEu5-focaTwA6b_GY1m5fKd-6CTpq0pvc5HEGkadw@mail.gmail.com> (raw)
In-Reply-To: <20210107154818.GB25249@tarpaulin.shahaf.local2>
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]
On Thu, Jan 7, 2021 at 7:48 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > > > 1) the bit representing "remember that this was declared but no value
> > > > was assigned"
> > > > 2) the combination of that with PM_UNSET that represents
> "functionally
> > > > behaves like NULL"
>
> After «unset», PM_UNSET would be set, and I don't immediately see why
> bit #1
> should be tested at all if if PM_UNSET is set.
Bit #1 is tested for "typeset -p var". If PM_UNSET is set and bit #1 is
not, then "typeset -p" outputs nothing; but we want typeset -p to output a
declaration (with no assignment).
> If the «unset» is followed by
> an assignment and/or (re-)declaration, the value of bit #1 can then be set
> properly, and PM_UNSET cleared. Makes sense?
>
Bit #1 has to be cleared on explicit unset, and is irrelevant on assignment
because PM_UNSET is cleared on assignment. However, it's most convenient
to clear bit #1 on assignment because that eliminates one special case on
"typeset var=value" (as opposed to "typeset var").
[-- Attachment #2: Type: text/html, Size: 1628 bytes --]
next prev parent reply other threads:[~2021-01-07 22:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-28 22:13 Felipe Contreras
2021-01-03 1:18 ` Bart Schaefer
2021-01-03 2:38 ` Felipe Contreras
2021-01-03 18:26 ` Bart Schaefer
2021-01-04 6:17 ` Daniel Shahaf
2021-01-04 21:57 ` Bart Schaefer
2021-01-06 16:02 ` Daniel Shahaf
2021-01-06 17:33 ` Bart Schaefer
2021-01-07 15:48 ` Daniel Shahaf
2021-01-07 22:29 ` Bart Schaefer [this message]
2021-03-27 19:24 ` Lawrence Velázquez
2021-03-27 20:42 ` Bart Schaefer
2021-03-29 0:44 ` Oliver Kiddle
2021-04-10 18:56 ` Bart Schaefer
2021-04-10 21:58 ` Oliver Kiddle
2021-04-10 22:35 ` 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='CAH+w=7a8YBEu5-focaTwA6b_GY1m5fKd-6CTpq0pvc5HEGkadw@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=d.s@daniel.shahaf.name \
--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).