Re: If someone wants to try...

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx