Somewhat unexpected results of {myfd}>&1 when noclobber set

[Mikael Magnusson <mikachu@gmail.com>]

(You can skip this most of this part, just included some variations for fun)
% setopt noclobber
% : {foo}>&1
% echo $foo
15
% bar=7+8
% : {bar}>&1
zsh: can't clobber parameter bar containing file descriptor 15
% bar=foo
% : {bar}>&1
zsh: can't clobber parameter bar containing file descriptor 15
% bar=( 14 15 )
% : {bar}>&1
zsh: bad math expression: operator expected at `15'
% echo $bar
16
% bar=foo
% : {bar}>&1
zsh: can't clobber parameter bar containing file descriptor 15
% foo=
% : {bar}>&1
zsh: can't clobber parameter bar containing file descriptor 15
% echo $bar
15
(at this point bar somehow became of type "integer", i think after it
was an array, so the earlier assignment bar=foo resolved foo to 15).

Of course, all these are the result of the fact that when the
clobbering is checked, the parameter name is passed to getintvalue()
which does mathevali() on the contents (possibly after joining if it
was an array). Should we perhaps instead explicitly check that the
parameter is a) a scalar b) just do atoi() or whichever function is
best for this, and compare directly?

I think it's at least not expected that this parameter is only subject
to math evaluation if the clobber option is unset.

-- 
Mikael Magnusson