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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 5,  5:23pm, Peter Stephenson wrote:
} Subject: Re: [PATCH][RFC] check for heap memory in zfree()
}
} Bart Schaefer wrote:
} > 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.
} 
} 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.

Knowing a bit about how PF thinks, that's probably the right answer.

Any objections to my committing my patch?  With one additional tweak
to call zheapptr() before zarrdup() in the builtin.c hunk.
 
} 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?

schaefer[514] typeset -T DIRSTACK dirstack
typeset: dirstack: can't change type of a special parameter

IMO a unique array is a distinct type from an ordinary array.

} 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).

Some of our quacking and waddling parameters are already dog-paddling.
For example, although you can (without getting warnings) set the -LRZ
options on any array, they don't have any effect except to make the
array show up in "typeset -LRZ" output.

} 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 think you're only half right.  Efficiency isn't the problem when it
comes to having an internal construct like the dirstack linked list
made visible via an array parameter -- the problem is that there's no
way for the other code that manipulates the structure to know that
the parameter exists and has its own value rules.  The way to fix
that is to require that the parameter's rules conform to the internal
structure it represents, not the other way around.