Re: PATCH: "typeset -m" plays havoc

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sep 14, 11:20am, Bart Schaefer wrote:
}
} Bad Things happen in every version of zsh back to 2.4 if you specify other
} type-declaration flags with -m.

Staring at this for a bit convinced me that, at least in recent versions
of zsh, this can't really have anything to do with `-m'.  What it means
is that zsh is not robust in the face of certain "nonsense" typesets of
variables that it uses -- any bad thing you can make happen with `-m' it
should be possible to make happen without it.

Here's an example:

    erase_PS1() { typeset PS1 prompt PROMPT }

Run that function, and your prompt will disappear, even though all it does
(supposedly) is declare local parameters with the same names.  (This bug
can't happen in older versions where those parameters are "special".)  The
bug doesn't happen if you use `typeset PROMPT prompt PS1', but with any
other ordering you erase all three by making any two or more of them local.

Similar things can be caused to happen to any of the other non-special,
scalar variables that are "tied" (PS2/PROMPT2, histchars/HISTCHARS, etc.)
as long as you make them local in the right (er, wrong?) order.

Another example:

    flush_history() { typeset HISTSIZE }

In fact, the above examples cover all the bad behavior that caused me to
notice the problem with `typeset -m' in the first place.

Other crashes happen when changing the type of assorted variables that zsh
uses.  Here's a good one:

    PS1='%m%# '
    HOST=()

If HOST is an empty array and any prompt-expansion string uses "%m", zsh
will dump core.  This is new as of zsh-workers/12247.

Next there appears to be a bad interaction between auto-zmodloaded special
parameters and builtin.c:typeset_single().  Normally typeset_single() will
choke with "can't change type of a special parameter", but that appears to
be tested too early -- the parameter may come into existence because of
autoloading between the time the PM_SPECIAL flag is tested and the time
the change-of-type is attempted.  This leads to a core dump.  This does
look like a bug strictly with `-m', having to do with the way that the
parameter hash table is searched when doing the pattern match:  The auto-
loaded parameters are in the table but have none of their flags set yet.

That's all I have time to hunt around for right now, but it does look as
if it's not necessary to force `typeset -m' to work on globals.  AFAICT,
the reason it worked this way in previous versions was because of the
parameter table search:  Since you can't possibly refer to a non-existing
parameter with `typeset -m', you must therefore be referring to the one
that already exists.  Now that we have `+g', though, there's no reason
one can't say "find this global parameter and force it to be local".  So
I'll send a revised patch (a subset of Andrej's 12806, really) as soon as
I have time to revise the doc slightly to match.

That patch probably *won't* address the list of problems above, though ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net