Re: [PATCH] declarednull: felipec's approach

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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:

ubuntu% () {
function> local foo
function> readonly foo
function> typeset -p foo
function> print x${(t)foo}x
function> }
typeset -r foo
xscalar-local-readonlyx
ubuntu%

More generally, I'm a little concerned by the vunset hunk in
Src/subst.c.  When working on declarednull, I tried a LOT of
variations of fiddling with vunset without getting consistent
behavior. I should have preserved them as test cases, but didn't
because the "make check" suite was not passing everything anyway.
Most involved things like ${+array[x]} for arrays and hashes.

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.