From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: zsh-workers-request@euclid.skiles.gatech.edu
Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by coral.primenet.com.au (8.7.5/8.7.3) with ESMTP id IAA13239 for <mason@primenet.com.au>; Wed, 13 Nov 1996 08:30:56 +1100 (EST)
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id QAA15222; Tue, 12 Nov 1996 16:29:04 -0500 (EST)
Resent-Date: Tue, 12 Nov 1996 16:29:04 -0500 (EST)
From: Zoltan Hidvegi <hzoli@cs.elte.hu>
Message-Id: <199611122129.WAA13225@bolyai.cs.elte.hu>
Subject: Re: problem with multios on irix 5.3, zsh 3.0.1
In-Reply-To: <9611122110.AA08691@dbank> from "rjones@pobox.com" at "Nov 12, 96 02:09:56 pm"
To: rjones@pobox.com
Date: Tue, 12 Nov 1996 22:29:29 +0100 (MET)
Cc: zsh-workers@math.gatech.edu
Organization: Dept. of Comp. Sci., Eotvos University, Budapest, Hungary
Phone: (36 1)2669833 ext: 2667, home phone: (36 1) 2752368
X-Mailer: ELM [version 2.4ME+ PL27 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"tPra5.0.mj3.VmEYo"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/2383
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

rjones@pobox.com wrote:
> i built zsh 3.0.1 "out-of-the-box", didn't get any compiler errors,
> etc. on an irix 5.3 system.
> 
> i discovered this possible bug:
> 
> in a directory with a large number of files:
> 
> % cat < * > /dev/null
> 
> this gives a seg fault on irix.  on solaris, according to a friend, it
> just stops at the 54th file.  my best guess is that the fdtable is
> filling up.  there don't seem to be any upper-bounds checks in the
> functions in util.c that deal with fdtable.  no lower bound check in
> zclose, either, so sometimes max_zsh_fd can go beyond the end of the
> array or go negative (unless there's some invariant condition that keeps
> it from going negative.  some debugging seemed to indicate that it was
> going neg, though.).

It may be the problem.  The lower bound check was missing indeed and it was
fixed a few weeks ago.  The upeer bound check is not necessary if the
fdtable is as big as the maximum number of open file descriptors of the OS.
Try to modify the

#  define OPEN_MAX 20

line in system.c, give it a bigger value (64 or 256) and see if it stops
the coredump.  The missing lower bound check is of course a bug but it
cannot cause coredumps or any noticable problems.

> fdtable[pipes[!out]] = 2;
> 
> it may be ansi-acceptable to trust "!" to always return 0 or 1, but
> this would probably be easier to read if it were
> 
> fdtable[pipes[out ? 0 : 1]] = 2;

out is always zero or one here.  Here is a piece of code:

        zclose(pipes[out]);
        fdtable[pipes[!out]] = 2;

In that case !out is more clear and it really means the opposite of out.
Writing out ? 1 : 0 produces less efficient machine code.

Zoltan