Re: Possibly excessive WARN_CREATE_GLOBAL

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 23,  3:49pm, Peter Stephenson wrote:
} Subject: Re: Possibly excessive WARN_CREATE_GLOBAL
}
} On Sun, 22 Nov 2015 12:30:28 -0800
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > We come into createparam() and discover at line 878 that the parameter
} > already exists, which is what we want, but in spite of it being flagged
} > PM_SPECIAL|PM_REMOVABLE all createparam() does is toggle off the PM_UNSET
} > flag, which seems dubious.
} 
} Being special and removable shouldn't stop you re-enabling the parameter
} --- this test has nothing to do with scope here, it's just recreating
} the parameter as you've asked it to do.  (It's not checking PM_HIDE here,
} or you might think that was useful.)

It took me a while to figure out how to explain why I think this is
dubious, but finally decided it comes down to this:  Toggling PM_UNSET
off here without calling the GSU setfn implicitly provides a default
value for the parameter, which is sort of OK for normal parameters but
wrong for PM_SPECIAL.  If nothing else, it means the getfn has to be
prepared to return something even if the setfn has never been called.

(Of course theoretically the setfn was called with NULL before the
PM_UNSET flag was set in the first place, but also theoretically the
setfn could make use of the state of PM_UNSET at the time of call.)

Unfortunately none of the standard setfn do anything with PM_UNSET;
they all rely on it having been cleared by createparam(), so a change
there could have far-reaching effects.  Not something to do while a
release is imminent.

} Perhaps what it should be doing is creating a new one in the inner
} scope that hides the private one as the least bad effect.

What should happen is that it creates a new one at global scope, and
trips warncreateglobal if necessary.  Which DOES happen if the one at
global scope was previously assigned and/or explicitly declared.  The
difficulty only arises when the private parameter is at the outermost
scope where any parameter of that name can be found.

} Or, possibly in this case, it should be an error that tells you need to
} use "typeset" to override a private variable in a local scope.

It might be possible to pull this off, but probably not until it's too
late for the PM_UNSET flag to have been (in)correctly handled.