zsh-workers
 help / color / mirror / code / Atom feed
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   


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