From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21286 invoked from network); 31 Oct 2000 14:01:12 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 31 Oct 2000 14:01:12 -0000 Received: (qmail 24186 invoked by alias); 31 Oct 2000 14:01:06 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13103 Received: (qmail 24179 invoked from network); 31 Oct 2000 14:01:05 -0000 Date: Tue, 31 Oct 2000 15:01:03 +0100 (MET) Message-Id: <200010311401.PAA00843@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Tue, 31 Oct 2000 13:51:35 +0000 Subject: Re: zsh-3.1.9-dev-6 crashes occassionally Peter Stephenson wrote: > Sven wrote: > > + ALLOWTRAPS { > > + while ((r = read(SHTTY, &cc, 1)) != 1) { > > I suppose you've thought this through more than I have, but wouldn't it be > safer just to run traps every time the read returns? I'm assuming a signal > arriving will interrupt the read in any case, so as far as I can see it's > pretty much equivalent in practise. There's nothing too nasty in the block > underneath, but it does call zrefresh() and attachtty() which are probably > best treated as black boxes. Hmhm. I was about to say that traps are only insecure when they can execute code the non-trap code currently executes, but, yes, since one can invoke more and more code from shell code... Maybe I should have a second (third, fourth,...) look to see if we can get rid of this ALLOWTRAPS { ... } DISALLOWTRAPS stuff altogether. That would make me more comfortable, I think. Unless someone knows of a system where signals don't interrupt things like read. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de