Re: [PATCH][RFC] check for heap memory in zfree()

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

Bart Schaefer wrote:
> I'm not entirely happy with either of these because both needlessly
> duplicate memory in the case where the array is already free-able.
> It seems as if it should be possible for "typeset -U" to be made more
> efficient than assignment-by-copy.
>...
> Maybe someone can remind me why it's up to the parameter set-function
> to free its argument?  That seems completely inside-out to me.

This second is the nub of the problem.  The API (if that isn't an
overgrand way of putting it in this case) requires the value to be
assigned permanently.  For normal parameters this is typically more
efficient (I presume; I haven't followed it through to make sure) since
there's no additional copy; it's just assigned to the array variable and
the old value is freed.  In this case we are doing something slightly
suspicious to make a feature implemented rather differently behave like
a parameter.

Later:
> } OR you guys are now going to say: "Don't you know you're not supposed
> } to use typeset with dirstack!!"
> 
> You aren't, but the shell isn't supposed to crash, either.

Why not?  If you weren't supposed to do that kind of thing, dirstack
wouldn't be writeable.  Since it is, this needs to be handled
transparently.  If it quacks like a parameter and waddles like a
parameter, a user should assume it swims on water like a parameter (er,
as it were).

It seems to me that behind both of these is the tension between the
ability to make a feature look like a parameter and efficiency of
implementation for normal parameters.  I don't see how we can do both,
except with lots of ad hoc testing for specialness, which fixes the
problem at the expense of yet more complexity.  That is at least the
standard zsh way out.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page still at http://www.pwstephenson.fsnet.co.uk/