Re: [PATCH] declarednull: felipec's approach

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Sun, Dec 27, 2020 at 4:06 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Dec 23, 2020 at 3:47 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > I added a test that shows a discrepancy I found (${(t)var}) but there
> > could be many, may more. I only checked one instance of PM_UNSET.
>
> Here's one that your patch gets (I think) wrong:
>
> ubuntu% setopt posixbuiltins
> ubuntu% () {
> function> readonly foo
> function> typeset -p foo
> function> print x${(t)foo}x
> function> }
> xx
> ubuntu%
>
> (Note "typeset -p" output nothing.)  On declarednull without your patch:
>
> ubuntu% setopt posixbuiltins
> ubuntu% () {
> function> readonly foo
> function> typeset -p foo
> function> print x${(t)foo}x
> function> }
> typeset -g -r foo
> xx
> ubuntu%
>
> The typeset output probably comes down to your third hunk in
> Src/params.c (printparamnode), although I'm not certain what the
> correct fix is, and I don't know what's up with ${(t)foo}.  The
> behavior with your patch changes if it's done this way:

I see. I would need to check that case.

> One other thing that has me scratching my head about your patch ... I
> can't see any reason why it matters that the bit value is (1<<30), but
> if I try, for example, overloading (1<<22) as I did for PM_DECLARED,
> the argument lists of shell functions stop working.

Because some variables have initially the flag PM_DONTIMPORT (1<<22),
for example IFS, so it's like initially they don't have any value
(i.e. PM_NULL).

Cheers.

-- 
Felipe Contreras