Re: [PATCH] declarednull: felipec's approach

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Mon, Dec 28, 2020 at 3:00 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Dec 28, 2020 at 12:09 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > 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:
> > > >
> > > 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).
>
> Yes, but nothing ever looks at PM_DONTIMPORT after setting up the
> parameter table,

Not PM_DONTIMPORT, but PM_NULL (which have the same value).

> and how did the positional parameters get involved,

static initparam argvparam_pm = IPDEF9("", &pparams, NULL, \
PM_ARRAY|PM_SPECIAL|PM_DONTIMPORT);

> and why does that NOT happen on the "raw" declarednull branch?

Because in that branch you never check PM_DECLARED alone; it's always
with PM_UNSET.

> I guess it has to be something that's not in your diff but that's
> looking for exactly the PM_NULL bit-pattern, such that omitting
> PM_UNSET makes that comparison fail.

Yes.

Perhaps clearing the flag after calling dontimport() would make sense.

-- 
Felipe Contreras