From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: If someone wants to try...
Date: Wed, 19 Jan 2000 15:02:19 +0100 (MET) [thread overview]
Message-ID: <200001191402.PAA13993@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Wed, 19 Jan 2000 12:48:50 +0000
Peter Stephenson wrote:
> If all the basic things get fixed, I'm tempted to put the whole thing in to
> the source and see what happens. In particular, I'm not sad that
> dupstruct() and all its relatives have vanished. That was the main use for
> having routines that either used the heap or permanent allocation. If this
> means we're now (nearly) in a position to use either explicitly, and hence
> junk all the HEAPALLOC/PERMALLOC stuff, it would make me very happy.
Right
> Problems:
>
> First `[ ... ]' dumps core. Is this the right fix (the middle parse.c
> hunk)? It seems to work. I've added a debugging test for other unhandled
> codes, and a couple of tests to Test/07cond.ztst (strictly these were
> waiting for tests for builtins to come along, but the more the merrier).
Yes, it's ok. I hadn't remembered parsecond().
> Second:
>
> % [[ ( -z foo && -z foo ) || -z foo ]]
> zsh: bad cond code
>
> It looks like the offsets for skipping chunks of `&&' and `||' weren't
> right. The text.c bit did work (e.g. if you embed that test in a function
> and look at it), so I've assumed it's the chunk in evalcond() that's
> wrong. The offsets now seem to be right, although it's possible I've been
> unnecessarily conservative in using variables. I've added a test for this,
> too.
Right again. Dunno how I could forget that the evalcond() would have
changed *state->pc at the point where the new pointer was calculated
(maybe it was because I didn't have to change it).
> Third, the point already noted by Tanaka Akira, but fixed by Sven in 9361,
> which boils down to:
> unset NULLCMD
> print "$(<anyfile)"
> zsh: redirection with no command
>
> Looking more closely, the problem occurs at the test in getoutput() which
> should pick up anything that's a simple read redirection and treat it
> specially. This wasn't happening because there was no WC_END marker at the
> end of the wordcode programme. According to parse.c, WC_END only gets put
> there if the programme is empty, so this is not surprising, hence Sven's
> fix.
>
> But the fact that there's no marker unsettles me from another point of
> view, namely execlist() ploughs on until it something which isn't a
> WC_LIST, and if there's no WC_END marker it can in principle find any old
> rubbish --- it seems usually to be the strings needed by the programme. So
> I would think that adding a WC_END marker unconditionally is the right
> thing (four bytes per programme isn't so much). I'm willing to take higher
> counsel --- which means, if Sven can explain what I've missed about the
> code that makes sure it knows when it's at the end of the programme. I've
> added another redirection test to pick this up. This would make 9361
> unnecessary, although maybe it would still be desirable?
I was tempted to leave it in (yes, I once had it). But then I made
`sure' that execlist() was correct so that we don't need it --
forgetting to change getoutput() then. The important bit is in
exec.c:841. ltype holds the type of the list that was just executed
and all lists `at the end' (of a function, loop, etc) have Z_END.
But of course, 4 bytes per eprog isn't that much.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2000-01-19 14:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-01-19 14:02 Sven Wischnowsky [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-01-20 8:26 Sven Wischnowsky
2000-01-19 15:46 Sven Wischnowsky
2000-01-19 19:38 ` Peter Stephenson
2000-01-19 8:59 Sven Wischnowsky
2000-01-19 11:05 ` Alexandre Duret-Lutz
2000-01-18 10:09 Sven Wischnowsky
2000-01-17 12:50 Sven Wischnowsky
2000-01-18 22:49 ` Tanaka Akira
2000-01-19 12:48 ` Peter Stephenson
2000-01-19 12:53 ` Peter Stephenson
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=200001191402.PAA13993@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.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).