From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: Re: Nasty bug in array-element typeset assignments
Date: Thu, 26 Jul 2001 17:49:30 +0000 [thread overview]
Message-ID: <1010726174930.ZM23256@candle.brasslantern.com> (raw)
In-Reply-To: <000001c115d6$50e082c0$21c9ca95@mow.siemens.ru>
Good grief, this is the most discussion on a single topic in weeks. I
shouldn't have gone to bed last night, I guess.
On Jul 26, 10:44am, Peter Stephenson wrote:
}
} When you add to this the restore sequence, which is handled at the
} end of function scope with no detailed knowledge of what typeset has been
} up to, you've got something very difficult to maintain
It's not supposed to create a local *element*, it's just supposed to
assign to an element of a local array.
On Jul 26, 1:57pm, Borsenkow Andrej wrote:
}
} BTW it is allowed in 4.0.2, I do not have earlier versions here readily
} available. May be, it was always possible?
See 14060, as Andrej already mentioned -- it was always possible, but
badly broken. It seemed useful to me, so I tried to fix it rather
than prevent it.
I discovered the bug when writing this:
function example() {
local 'new_array[$#new_array+1]'=$^old_array
# ...
}
The above works beautifully, and is equivalent to what you'd get if the
syntax `local new_array=( $old_array )' worked.
In fact, the following also works, and does not cause a core dump:
function example() {
local path 'path[$#path+1]'=$^path
# ...
}
Because in the above statement, `path' is made local before the elements
are assigned. Et voila.
On Jul 26, 12:07pm, Oliver Kiddle wrote:
}
} I wrote:
} > However, I wouldnt have thought it'd be too
} > hard to get it to print an error message for the above case.
}
} This might be useful for 4.0.2 so the following is a patch to do that
} much.
There was never any patch following ... but that's just as well, because
I don't want to print an error in this case, unless possibly the array
is non-local.
On Jul 26, 12:38pm, Oliver Kiddle wrote:
}
} > Probably, intent was to create new local array.
}
} Urgh. Is that really that useful?
It's really useful (see above), but it's not really necessary (also see
above).
} Also, if this is fixed to make the whole array local but the fix is
} complicated then this small change might be a good option for the 4.0
} branch.
I think there's a simple fix we can do without disallowing it entirely.
On Jul 26, 12:45pm, Peter Stephenson wrote:
}
} Something like that would definitely be my preference.
I have something working that's actually a very small change, and still
permits my second example above to work (while rejecting the first one).
Let me play with a few more cases so I can put the right regression tests
in D06 -- it'll probably be several hours before I get to concentrate on
it.
--
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
next prev parent reply other threads:[~2001-07-26 17:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-26 5:13 Bart Schaefer
2001-07-26 9:23 ` Peter Stephenson
2001-07-26 9:28 ` Borsenkow Andrej
2001-07-26 9:44 ` Peter Stephenson
2001-07-26 9:57 ` Borsenkow Andrej
2001-07-26 10:04 ` Oliver Kiddle
2001-07-26 11:07 ` Oliver Kiddle
2001-07-26 11:08 ` Borsenkow Andrej
2001-07-26 11:18 ` Borsenkow Andrej
2001-07-26 11:38 ` Oliver Kiddle
2001-07-26 11:45 ` Peter Stephenson
2001-07-26 12:21 ` PATCH: posixbuiltins test (was Re: Nasty bug in array-element typeset assignments) Oliver Kiddle
2001-07-26 13:24 ` Nasty bug in array-element typeset assignments Borsenkow Andrej
2001-07-26 17:49 ` Bart Schaefer [this message]
2001-08-12 18:55 ` PATCH (?): " Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1010726174930.ZM23256@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).