From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29132 invoked from network); 4 Feb 2000 09:09:21 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Feb 2000 09:09:21 -0000 Received: (qmail 23153 invoked by alias); 4 Feb 2000 09:08:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9555 Received: (qmail 23145 invoked from network); 4 Feb 2000 09:08:46 -0000 Date: Fri, 4 Feb 2000 10:08:43 +0100 (MET) Message-Id: <200002040908.KAA21594@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Thu, 3 Feb 2000 17:40:22 +0000 Subject: Re: Infinite loop (bug in wordcode evaluation?) Bart Schaefer wrote: > } The problem is that none of the functions in loop.c check if retflag > } is set and hence don't return. But this was not changed by the > } wordcode stuff -- and a older zsh without that I have here behaves > } the same. In fact, I think that zsh behaved this way either always or > } for a long time. > > I can't find any loop construct in 3.0.7 that produces this behavior, > yet 3.0.7 does not have any of those extra retflag tests in loop.c. > > Does anyone know what else might have changed to cause this problem? > I want to understand it so that I don't leave a bug in 3.0.8. Found it. getkey() in zle_main.c now resets `breaks' to the value it had before, so that the new value stored in bin_break() set by the signal handler doesn't make it through to the execution code. Dunno where this comes from, though. If it turns out that this is wrong (at least doing it unconditionally as we do it now), we can remove the tests in loop.c again. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de