>Number:         5848
>Category:       bin
>Synopsis:       sh makes poor assumptions about pipe buffer sizes
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 25 20:35:00 1998
>Last-Modified:
>Originator:     David A. Holland <dholland@eecs.harvard.edu>
>Organization:
   - David A. Holland             |    VINO project home page:
     dholland@eecs.harvard.edu    | http://www.eecs.harvard.edu/vino
>Release:        1.3
>Environment:

	This problem appears in the 1.3 release source for sh, and
	appears to remain in -current.

>Description:

	sh assumes a pipe can hold at least 4k, via the #define in
	redir.c that sets PIPESIZE to 4096.

	This assumption is not necessarily correct. 

	This value is only used to determine whether or not forking
	is needed when processing a << redirection. The upshot of 
	this is that under rare circumstances (`<<' is rare, and
	`<<' of large blocks is rarer, and worse, it doesn't always
	happen and I don't know why) the shell will mysteriously
	hang.

>How-To-Repeat:

	Build a kernel with 2K pipes (or build sh on a system with 2K
	pipes) and run the configure script from gnu binutils 2.8.2.

>Fix:

	At a minimum, the uses of PIPESIZE should be changed to
	PIPE_BUF.

	Either that, or the logic should be changed to always fork.
	This depends on whether the formal definition of PIPE_BUF and
	the circumstances of the write guarantee that the shell won't
	block. I believe that they do not guarantee this, but it is
	a matter for standards lawyers to argue over.

	Note that PIPESIZE is also defined but not used in init.c. 
>Audit-Trail:
>Unformatted: