[net.sources] 4.2 BUGLIST, part 7 of 10

vance@mtxinu.UUCP (Vance Vaughan) (11/09/84)

4.2 BUGLIST ABSTRACTS from MT XINU, part 7 of 10:

	The following is part of the 4.2 buglist abstracts as processed by
	Mt Xinu.  The initial line of each abstract gives the offending
	program or source file and source directory (separated by --),
	who submitted the bug, when, and whether or not it contained
	a proposed fix.  Due to license restrictions, no source is
	included in these abstracts.

	Important general information and disclaimers about this and
	other lists is appended at the end of the list...

script.c--ucb		    dlw@ucbopal.CC (David L. Wasley)   22 Nov 83   +FIX
	Some terminals must be used with parity checking enabled.
	'Script' doesn't generate parity so output is garbage.
	Also, RETURNs aren't stripped from the typescript and
	foul some other processes. (These come from using the
	pseudo-tty. They are necessary for the terminal output.)

    REPEAT BY:
	Run script on a terminal (eg tvi925) with parity checking
	enabled. Run 'od' on the typescript file.
_______________________________________________________________________________
sed--bin	     raphael@wisc-crys.arpa (Raphael Finkel)   29 Jun 84  
	Sed accepts only the pattern forms accepted by ed.  Vi has at least one
	improvement: delimited strings, formed by \< and \>.  This feature would
	enhance sed nicely.

    FIX:
	Embed code from ex into sed.
_______________________________________________________________________________
see--ucb	    ogcvax!root@teklabs.UUCP (Bruce Jerrick)   27 Apr 83   +FIX
	   In 4.1c, "/usr/src/ucb/see.sh" (and /usr/ucb/see) needs this added
	to the top:
	
		#! /bin/sh
	
	Without it, I get intermittent "see: Command not found." messages.
	
		Bruce Jerrick
		Oregon Graduate Center
		CSNet:  bruce@Oregon-Grad
		UUCP:   ...teklabs!ogcvax!bruce
_______________________________________________________________________________
select,getitimer,setitimer--man    cbosgd!mark (Mark Horton)   24 Aug 83   +FIX
	The documentation for select and getitimer should cross reference
	each other in the SEE ALSO section.  There should be a
	/usr/man/man2/setitimer.2 which is a link to or sources getitimer.2.

    REPEAT BY:
	whereis setitimer
	shows no manual page

    FIX:
	As in Description.  These two system calls have very similar
	function - in fact, I was using select to do what setitimer
	was designed for (a sub-second-resolution sleep).  They ought
	to cross reference each other.
	
	I trust you'll also fix the bugs Steve Bellovin pointed out in
	setitimer.  The documentation forgets to mention the first
	argument; also, setting it to zero to turn it off doesn't work.
	
	It's ironic that, even though setitimer was designed to be used
	as a timer and select wasn't, it's more convenient to use select
	because you don't have to mess with alarms.  Too bad select returns
	too soon.
_______________________________________________________________________________
sendbug--ucb			 mazama!stew (Stewart Levin)   9 Feb 84   
	This, though trivial, is too good to pass up.  Sendbug itself
	caused a bug!  make clean in /usr/src/ucb died when it entered
	the subdirectory `sendbug' because the makefile there did
	not have an entry `clean'.

    REPEAT BY:
	cd /usr/src/ucb/sendbug ; make clean

    FIX:
	add a clean entry to the makefile
_______________________________________________________________________________
sendbug/bugfiler.c--ucb       sjk@sri-spam (Scott J. Kramer)   7 Dec 83   
	When invoked with the -d, -mXXX, *and* maildir options,
	"bugfiler" returns a usage message and exits.

    REPEAT BY:
		bugfiler -d -m644 /usr/bugs/mail =>
			Usage: bugfiler [-d] [-mmsg_mode] [maildir]
_______________________________________________________________________________
sendbug/sendbug.sh--ucb		       hpda!hpdsd!hpdsa!eric   22 Mar 84   +FIX
	I resent being thrown into vi when reporting a bug.
	The user's environment should be interrogated for his/her
	EDITOR or VISUAL variables.

    REPEAT BY:
	Type "sendbug".  See vi(1) ?

    FIX:
	Using your favorite editor, look at /usr/src/ucb/sendbug/sendbug.sh
	Replace the line...
		/usr/ucb/vi /tmp/bug$$
	with...
		if ( $VISUAL != "" ) then
			set editor = $VISUAL
		else if ( $EDITOR != "" ) then
			set editor = $EDITOR
		else set editor = /usr/ucb/vi
		endif
_______________________________________________________________________________
sendmail--lib			mcgeer@ucbdali (Rick Mcgeer)   24 Jul 84  
	sendmail does not accept the following address, which is valid:
	"gladd tom@lll-mfe.arpa"
	instead it sends:
	gladd.tom@lll-mfe.arpa

    REPEAT BY:
	send mail to user gladd tom@lll-mfe.arpa, or to the postmaster at that
	site, "provan don"@lll-mfe.arpa
_______________________________________________________________________________
sendmail--usr.lib		      root@BERKELEY (Fluke )   5 Dec 83    +FIX
	If the sendmail alias database is out of date, two concurrent
	invocations of sendmail could each begin to update it in parallel.
	The resultant database may be garbaged.

    REPEAT BY:
	The following procedure is slightly non-deterministic, but it has
	been effective for us in provoking the problem 50% of the time:
	    Configure /usr/lib/sendmail.cf for automatic database rebuilding:
		# rebuild alias database if out-of-date:
		OD
	    Create /usr/lib/aliases.{dir,pag}
	    % touch /usr/lib/aliases.
	    % mail root </dev/null &
	    % mail root </dev/null &
	Now the tricky part -- test for bad aliases.  A short C program using
	the dbm(3) routines may be helpful.
_______________________________________________________________________________
sendmail--usr.lib		 mazama!stew (Stewart Levin)   11 Jan 84  
	After we installed sendmail we were getting messages complaining
	about unknown system name when mailing letters to each other.
	We looked around and changed the /usr/include/syslog.h file
	to reference our own system name rather than "localhost"
	and reinstalled.  Same results.  Finally we found that sendmail
	uses its own private copy of that file and the problem went
	away after repeating the change in /usr/src/usr.lib/sendmail/include.

    REPEAT BY:
	Install the distributed sendmail program.

    FIX:
	Do not distribute sendmail with private copies of system source
	codes.  Instances we find are:
	
	/usr/src/usr.lib/sendmail/aux/newaliases.c
	/usr/src/usr.lib/sendmail/aux/rmail.c
	/usr/src/usr.lib/sendmail/aux/newsyslog
	/usr/src/usr.lib/sendmail/aux/syslog.c
	/usr/src/usr.lib/sendmail/doc/syslog.3
	/usr/src/usr.lib/sendmail/doc/syslog.8
	/usr/src/usr.lib/sendmail/include/syslog.h
	/usr/src/usr.lib/sendmail/include/sysexits.h
	/usr/src/usr.lib/sendmail/lib/newsyslog.sh
	/usr/src/usr.lib/sendmail/lib/syslog.c
_______________________________________________________________________________
sendmail--usr.lib	     rhc@ucbopal.CC ( l'Innommable )   2 May 84    +FIX
	When truncated to 8 characters,
	the identifiers ``returntosender'' and ``returnto''
	become identical.

    REPEAT BY:
	Fortunately this prevents the sendmail code
	from compiling on our PDPs.

    FIX:
	Replace occurances of the identifier ``returntosender''
	by ``rtntosender'' in envelope.c and savemail.c.
_______________________________________________________________________________
sendmail--usr.lib	     rhc@ucbopal.CC ( l'Innommable )   2 May 84    +FIX
	The sendmail source provides a byte-moving subroutine called
	bmove.  Most of the sendmail code uses this.
	The 4.2BSD C library provides a byte-moving subroutine
	called bcopy.  Only code in headers.c invokes this.
	Our PDP C library does not have this subroutine.

    REPEAT BY:
	Try to make sendmail on a PDP without editing the source.

    FIX:
		Change the line in headers.c from ..
		bcopy (mopts, h -> h_mflags, sizeof mopts);
	.. to ..
		bmove (mopts, h -> h_mflags, sizeof mopts);
_______________________________________________________________________________
sendmail--usr.lib	     rhc@ucbopal.CC ( l'Innommable )   2 May 84    +FIX
	The sendmail source contains a byte-zero routine
	called clear. Several of the sendmail subprograms use it.
	The 4.2BSD C library contains a byte-zero routine
	called bzero. Several other of the sendmail subprograms use it,
	unfortunately, also.
	Our PDP C library contains no such routine.

    REPEAT BY:
	Try to make sendmail on a PDP.

    FIX:
		Change the invocations of bzero in the above files ..
	queue.c:	bzero ((char *) & nullmailer, sizeof nullmailer);
	readcf.c:	bzero ((char *) m, sizeof * m);
	sendmail.h:#define clrbitmap(map)		bzero((char *) map, BITMAPBYTES)
	.. to ..
	queue.c:	clear ((char *) & nullmailer, sizeof nullmailer);
	readcf.c:	clear ((char *) m, sizeof * m);
	sendmail.h:#define clrbitmap(map)		clear((char *) map, BITMAPBYTES)
_______________________________________________________________________________
sendmail--usr.lib    Liudvikas Bukys  <bukys@rochester.arpa>   6 Jun 84    +FIX
	The myhostname() generated if DAEMON is defined has two problems:
	(1) it calls gethostname() incorrectly (a holdover from pre-4.1a?);
	(2) it assumes that hp->h_name is the same as `hostname`.

    REPEAT BY:
	Go to a machine for which `hostname` is not the first name in
	the /etc/hosts line.  For example, on ur-seneca, whose
	/etc/hosts line looks like
		192.5.37.83	ur-seneca seneca sen
	`hostname` is "seneca", not "ur-seneca".
	Without this fix, sendmail's $w is (seneca) and $=w is (seneca sen).
	With this fix, $w is (ur-seneca) and $=w is (ur-seneca seneca sen).
_______________________________________________________________________________
sendmail--usr.lib	       Jay Lepreau <lepreau@utah-cs>   30 Jun 84  
	Sendmail was changed awhile ago to leave the escaping of
	'From ' lines to the local mailer.  Well, when it itself
	is the local mailer, as when going to files, I think it
	should do it.  At least somebody's got to, or sendmail should
	use a different message separating convention....

    REPEAT BY:
		Set up a mail alias to a 622 file, and mail the following to it:
	sendmail -t
	To: testfile
	
	line one
	
	From line three
	line four
	^D
	
	Then do a Mail -f <filename> and get two messages.
_______________________________________________________________________________
sendmail--usr.lib		    Yoon Kim <kaist!yoonkim>   13 Feb 84  
	When sendmail is compiled and run, a Segmentation fault error occurs.
	By using DBX, I narrowed down to malloc() call.  It is the first call
	to malloc() when this error happens.  (NOTE: The libsys.a problem is
	already fixed.)

    REPEAT BY:
	/usr/lib/sendmail (one of the any options here)
	i.e. /usr/lib/sendmail -q
_______________________________________________________________________________
sendmail--usr.lib		   Web Dove <dove@sylvester>   29 Jul 84  
		I was trying to send mail from my lisp machine to my vax using
	smtp, and the vax wouldn't accept a sender address of [128.31.27.16].
_______________________________________________________________________________
sendmail/aux/syslog.c--usr.lib		decvax!dartlib!steve   30 Nov 83  
	The periodic time mark message that syslog (the daemon) is supposed to
	generate only gets generated when the daemon is invoked with the 
	debugging option, -d.

    REPEAT BY:
	Invoke the daemon as "/etc/syslog" and you get no time marks.
	Invoke it as "/etc/syslog -d" and you get time marks (and other
	stuff).

    FIX:
	In regular - non-debugging - operation, the program forks, letting
	the parent exit(0) and the child become the daemon.  In debug
	mode, no fork is done.  The problem is that the initial call to
	alarm to set up the time mark is done before the fork, so in
	normal operation the SIGALRM is sent to the parent, which has exited.
	The child daemon never gets the first signal, so there are never
	any time marks.
	
	The fix is just to move the alarm call down after the fork.
	Doing "diff new old" yields:
	
	192a193,194
	> 	signal(SIGALRM, domark);
	> 	alarm(MarkIntvl*60);
	247,248d248
	< 	signal(SIGALRM, domark);
	< 	alarm(MarkIntvl*60);
_______________________________________________________________________________
sendmail/src/alias.c--usr.lib       Tim Mann <mann@Gregorio>   4 Oct 84    +FIX
	If the alias database is out of date, alias.c forces Verbose mode on
	while printing the above warning message, then sets it back to its
	previous state.  This has the effect of forcing the message to go
	out on the SMTP connection.  If the site at the other end of the SMTP
	connection is not running sendmail, the "050" code is meaningless to
	it and generally causes the mail transaction to fail.

    REPEAT BY:
	Touch your /usr/lib/aliases file without running newaliases, and make
	sure sendmail is not configured to update it automatically.  Then try 
	to send mail from a non-sendmail site and watch it get confused.

    FIX:
	There seems to be absolutely no reason to force Verbose on in this
	situation, so I fixed the problem locally by removing the three lines
	of code in alias.c that do it.
_______________________________________________________________________________
sendmail/src/collect.c--usr.lib    salkind@nyu (Lou Salkind)   22 Nov 83   +FIX
	If sendmail encounters end of file before a newline character,
	it can go into an infinite loop.
	The reason is that the EOF condition is never explicitly checked.

    REPEAT BY:
	Certain files received with smtp will cause this.
_______________________________________________________________________________
sendmail/src/collect.c--usr.lib			Bill Nowicki   12 Mar 84   +FIX
		Recently we have been having congestion problems in our
	Arpanet gateway.  This causes packets to be dropped, and eventually
	TCP connections to time out.  The sendmail SMTP daemon will return
	a message to the sender when the TCP connection times out during
	transmission.  It should instead just discard the partially-received
	message, since the sending host will send it again the next time
	the queue is run.  This bug causes our users to get copies of their
	outgoing mail returned hourly until the evening when our gateway
	congestion disappears and the message finally gets delivered properly.

    REPEAT BY:
		Send a large message from host A to host B, (say, "nobody@B")
	where host B is running sendmail.  After doing netstats on either host
	to determine that a TCP connection has been made, do a ps on host A
	and kill the sendmail process quickly before it completes.  You will
	get a message back from mailer-daemon@B saying "SYSERR:unexpected close".
	The next time the queue is run, however, the message is successfully
	delivered to the user on host B.
_______________________________________________________________________________
sendmail/src/collect.c--usr.lib		      stanonik@nprdc   2 Oct 84    +FIX
	If the smtp peer tcp resets while you're collect'ing
	the body of the message, then sendmail will loop, 
	rereading the last line received and adding it to the
	df file.

    REPEAT BY:
	I don't know how to reproduce this problem, but in our
	case the peer did this to us every half hour for 3 days,
	every time they had mail for us.
_______________________________________________________________________________
sendmail/src/conf.c--usr.lib rhc@ucbopal.CC ( l'Innommable )   20 Mar 84   +FIX
	Sendmail has two parameters which modify the delivery behaviour,
	that specified by the option ``d''.
	These are, QueueLA, option ``x'', the load average above which
	messages will be left in the queue for the daemon to deliver;
	and RefuseLA, option ``X'', the load average above
	which SMTP connections will be refused.
	These variables are statically initialized.
	Their values may be changed by command argument flags,
	or by options in the -.cf file.
	Because they are statically initialized,
	their values are not remembered in the ``frozen'' -.fc file.
	(Initialized static variables are allocated in .DATA,
	which is not saved in, nor loaded from, the -.fc.)

    REPEAT BY:
	Edit your sendmail.cf to contain suitably low values
	for these options, say
	Ox4
	OX6
	and make a new ``frozen'' config-file.
	/usr/lib/sendmail -bz
	(A) At a time when the load average is above,
	in this case, 4, send some mail, and observe that it
	is delivered, rather than being left in the Queue.
	- or -
	(B) At any time, kill the sendmail daemon
	with some core-generating signal, say 8,
	and inspect the wreckage:
	adb will show
	QueueLA/	8
	RefuseLA/	12
	the compiled-in default values.

    FIX:
	Don't initialize the values of QueueLA and RefuseLA
	in their declaration in conf.c.
		- AND -
	Make sure you have the options
		Ox<number>
		OX<number>
	in your sendmail.cf file.  Otherwise zero will be used.
	
	If you want to be careful, (I am not being careful here.)
	you might change the only two uses of these variables
	.../src/daemon.c:	while (getla () > RefuseLA)
	.../src/deliver.c:	if (getla() > QueueLA)
	to behave gracefully for values <= 0.
	Choose your own conception of graceful behaviour.
_______________________________________________________________________________
sendmail/src/parseaddr.c--usr.lib	  pur-ee!Physics:crl   24 Feb 84   +FIX
	In rewrite(), some calls to printav() were not in an
	#ifded DEBUG
_______________________________________________________________________________
sendmail/src/srvrsmtp.c--usr.lib	      Larry Peterson   12 Dec 83   +FIX
	We noticed that aliases were not being expanded on mail coming
	into the smtp server.  Locally generated mail was aliases correctly
	thus the vast majority of aliases worked correctly since sendmail
	delivers to a userid even if it cannot find it in the alias table.
	Also, our relay machine, which is running 4.1, had an older version
	of sendmail running, so aliases which came in from outside of our
	domain were handled correctly. It was only those aliases specific
	to our 4.2 machine that failed.

    REPEAT BY:
	Try sending mail to 'postmaster@hostA' from hostB, given that
	postmaster is an alias which is known on hostA, and that hostA
	and hostB communicate via an smtp connection and sendmail is
	running as daemon on hostA.

    FIX:
	I removed the initalias(AliasFile, FALSE) function call
	in the function 'runinchild' which can be found in srvrsmtp.c,
	and replaced it by the same function call at the first of the
	smtp function in srvrsmtp.c (i.e. before the inifinte loop).
_______________________________________________________________________________
sendmail/src/srvrsmtp.c--usr.lib	  pur-ee!Physics:crl   24 Feb 84   +FIX
	If DEBUG is defined, WizWord needs to be declared whether
	or not SMTP is defined.

    REPEAT BY:
	define DEBUG but not SMTP and compile.
_______________________________________________________________________________
sendmail/src/{deliver,srvrsmtp}.c--usr.lib     root@BERKELEY   5 Dec 83    +FIX
	The mail connection between Berknet and sendmail can be flakey.
	Incoming mail may be lost.  Complaints from MAILER-DAEMON may or
	may not be generated.
	
	N.B. this problem is related but not identical to the `bug' fixed
	in version 4.21 (11/1/83) of /bin/mail.

    REPEAT BY:
	The following command should deliver the arbitrary message read from
	STDIN.  Instead, the message is neither accepted nor returned; there
	are vague complaints of "Bad usage" and the message is lost.
	    % /usr/lib/sendmail -v -T10-11 -oee -r <from> -h 1 <to>
_______________________________________________________________________________
sendmail:--usr.lib   Liudvikas Bukys  <bukys@rochester.arpa>   8 Jun 84    +FIX
	Options specified on the command line are considered "sticky":
	they can't be overridden by later definitions on the command line
	or in the configuration file.  (This is fine.)
	
	Unfortunately, defining a macro on the command line sets the sticky
	flag for 'M' (macros), so subsequent macro definitions on the command
	line have no effect.  (This is not so good.)
	
	This is a pretty low-priority bug, since there's little reason for
	people to want to define more than one macro from the command line.
	But it would be nice if the bug disappeared from the "distribution".

    REPEAT BY:
	Stick a "$Z" someplace innocuous in sendmail.cf, like in a comment
	in the "Received:" line header.  Mail something to yourself with
		/usr/lib/sendmail -oMYTESTING -oMZ123 yourself < /etc/group
	See what the $Z expanded into; probably nothing; should be "123".
_______________________________________________________________________________
setreuid--man		    Spencer Thomas  <thomas@utah-cs>   22 Jan 84   +FIX
		The manual page for setreuid and setregid claim that "only the
	super-user may change the real user ID (group ID) of a process".  This
	is not true, inspection of the code in kern_prot.c shows that the real
	user ID may be set to the effective user ID by anybody.

    REPEAT BY:
	man setreuid

    FIX:
		Change it to read "Unprivileged users may change the real user
	ID to the effective user ID and vice-versa; only the super-user may
	make other changes."  (substitute group for user in setregid.2)
	
	=Spencer
_______________________________________________________________________________
sh--bin				   cbosgd!mark (Mark Horton)   9 Aug 84   
	The /bin/sh distributed with 4BSD is incredibly old - it's
	basically unmodified from UNIX/32V.
	
	I realize that nobody at Berkeley uses sh, I don't use it either.
	However, it is a good thing to put into makefiles and shell
	scripts, and there are people around (especially inside AT&T)
	who use it instead of csh, or who use the Korn shell.  There
	have been some good things put into it, for example, /etc/profile
	(a feature which csh could use too.)

    REPEAT BY:
	The particular bug came up when we tried to bring up the Korn
	shell on a Sun, which is 4.2 but isn't a VAX.  ksh tries to figure
	out what kind of system it's on automatically and compile itself
	accordingly with the right flags.  This results in code in the
	makefile like this:
		if test $(FIXDATA); then do one thing; else do another thing; fi
	where $FIXDATA is either the null string or "1".  On a VAX it's 1,
	so this works.  But on a Sun it's null, and when make invokes
	sh -e, if an if fails, the shell exits instead of doing one of
	the branches.  This terminates the make.

    FIX:
	Just get a more recent shell.  If the next BSD is going to require
	a System V license anyway, there's no problem.  Doug Gwyn (gwyn@brl)
	has a complete System V emulation package for 4.2BSD which includes
	a ported System V shell; perhaps it's easiest to get his.
_______________________________________________________________________________
sh--bin						    jdb@s1-c   12 Mar 84  
	There is a serious security problem when using set-uid and/or
	set-gid directly-exec'able command files (i.e. those starting
	with "#!").  The problem is best demonstrated by example.
	Consider the file "/usr/local/rootdate", setuid root, containing
	
		#! /bin/sh
		# Run "date" as root
		date
	
	The following sequence is used to obtain an interactive
	setuid-root shell:
	
		$ ln /usr/local/rootdate /usr/tmp/-
		$ cd /usr/tmp
		$ -
	
	When the shell is run to process the command file its argv list
	is {"-", "-", NULL} so it assumes that it should read the standard
	input.  It also looks for the user's ".profile" file.  (The
	reading of ".cshrc" can be avoided by using "#! /bin/csh -f".)
	
	In 4.1BSD the problem occurs when the setuid file resides on a
	filesystem on which a user may create a link, e.g. linking from
	"/usr/local" to "/usr/tmp".  In 4.2BSD the setuid file may be
	anywhere because a symbolic link can be used.

    REPEAT BY:
	See above.
_______________________________________________________________________________
signals--sys				      mayo@ucbrenoir   2 Feb 84   
	Some tty ioctl calls hang if invoked from a procedure that was
	invoked as the result of a SIGCONT signal.

    REPEAT BY:
	/*
	* This program demonstrates a possible problem with Berkeley UNIX.
	* It seems that you cannot do some 'ioctl's inside of a procedure
	* that is invoked in response to a signal.
	*
	* To see the problem, run this program in the forground.  Then stop it
	* using ^Z (or whatever).  Now run it in the background.  It should
	* stop on a 'tty output'.  Everything is fine up to now, but now
	* move the program to the forground.  AH HA!  You are now totally
	* dead in the water.
	*/
	
	#include <stdio.h>
	#include <signal.h>
	#include <sgtty.h>
	
	struct sgttyb tx_sgtty;
	
	sigOnResume()
	{
	   printf("\n<< Resume >>\n");
	   ioctl(fileno(stdout), TIOCSETP, (char *) &tx_sgtty);  /* <-- hangs here */
	   printf("\n<< Done With Resume >>\n");
	}
	
	main()
	{
	   ioctl(fileno(stdout), TIOCGETP, (char *) &tx_sgtty);
	   signal(SIGCONT, sigOnResume);	
	
	   while(1)
	   {
	       printf(".");
	       fflush(stdout);
	       sleep(1);
	   }
	}
_______________________________________________________________________________
sigpause--man      ssc-vax!jeff@lbl-csam (Jeffrey Jongeward)   20 Jun 84   +FIX
	sigpause(2) states that 'sigpause ..... returning EINTR'.
	However, that's not right; actually, it returns -1 and
	sets errno to EINTR.

    FIX:
	Make indicated change to man page.
_______________________________________________________________________________
sigvec.2--man		       lepreau@utah-cs (Jay Lepreau)   7 Nov 83   
	3rd param, "ovec", isn't documented at all, except for
	its existence & type.
	Is it a result param containing the old values?

    REPEAT BY:
	man sigvec
_______________________________________________________________________________
socket.2--man			  Chris Kent <kent@BERKELEY>   10 Jun 83  
		There is inconsistency about the socket() sys call between the
	4.1c UPM, the 4.2bsd System Manual, and the 4.2bsd IPC Primer. The UPM
	and IPC claim socket has 3 arguments; the SM claims 4, and neither is a
	proper sub-/super-set of the other.
	
		The UPM entry also references a non-existent manual page
	"socketopt(2)". 
	
		The IPC Primer doesn't indicate any way to set options on a
	socket.

    REPEAT BY:
	Read the manuals.

    FIX:
		Apparently the socket() call now has three arguments; the four
	argument version is from 4.1a. It would also seem that the calls
	"getsockopt()" and "setsockopt()" exist. These all need to be
	documented.
_______________________________________________________________________________
stand/boot.c?--sys		  Chris Kent <kent@BERKELEY>   15 Jun 83   +FIX
		The boot program doesn't understand how to interpret symbolic
	links at boot time.

    REPEAT BY:
		Make /vmunix a symbolic link to the actual kernel you want to
	run and try to boot. Boot reports "bad format" and gives up.
	
		Using symbolic links is a win if you have multiple experimental
	kernels around and would like to keep track of what's what, but don't
	want to have ps, w, uptime, rwhod, etc. be confused.
_______________________________________________________________________________
stand/hp.c--sys			  mazama!thor (Jeff Thorson)   10 Mar 84   +FIX
	Up to now we have not been able to boot directly off of an
	Eagle drive using the standalone 'boot' from the console
	floppy. Boot returns the diagnostic 'not a directory'.
	The fix below reveals that the problem appears when an
	Eagle (or other non-DEC drive which must be identified by
	the HPSN register) resides on mba1, mba2, or mba3.

    REPEAT BY:
	B ANY
	boot: hp(24,0)vmunix   (our Eagles reside on TR11)

    FIX:
	In /sys/stand/hp.c, replace
		hp_type[unit] = hpmaptype(hpaddr, i, unit);
	with
		hp_type[unit] = hpmaptype(hpaddr, i, UNITTODRIVE(unit));
	That is, hpmaptype() expects the massbus unit number (0-7).
	
				Jeff Thorson
				Stanford University Dept. Geophysics
				mazama!thor
_______________________________________________________________________________
stand/hp.c--sys    ssc-vax!jeff@lbl-csam (Jeffrey Jongeward)   20 Jun 84   +FIX
	'st' isn't set after 1st call to hpopen().   This
	means that disk partition offset info will be garbage, 
	and programs (like format) that could open/close a hp-style 
	disk more than once will fail after the first invocation.
	Repeat by:
	Run format 2 X on a drive w/o reloading from disk/casette.
_______________________________________________________________________________
stdio.h--misc			      joe@fluke (Joe Kelsey)   26 Jul 84   +FIX
	Remember all of the flack recently about sign extension and
	getc?  Whether or not you can compare (c = getc(stdin)) == EOF?
	Well, how about the same discussion related to putc?  Yes, there
	are programmers who check the value returned by putc.  The main
	problem is to detect errors indicated by _flsbuf, as in quota
	exceeded, or other disastrous errors.  However, putc(0xff, stdout)
	gets sign extended (on DEC hardware, anyway) so that you can't
	tell it from EOF (-1).

    REPEAT BY:
	#include <stdio.h>
	
	main()
	{
		int x;
	
		if ((x = putc(0xff, stdout)) == EOF) {
			printf (stderr, "Error!\n");
		} else {
			printf (stderr, "OK!\n);
		}
	}

    FIX:
		Add a mask to the putc macro in <stdio.h>.  Note that I have verified
		this bug in VAX-11 C also!
	old:
	#define putc(x,p) (--(p)->_cnt>=0? ((int)(*(p)->_ptr++=(unsigned)(x))):_flsbuf((unsigned)(x),p))
	new:
	#define putc(x,p) (--(p)->_cnt>=0? ((int)(*(p)->_ptr++=(unsigned)(x)))&0xff:_flsbuf((unsigned)(x),p))
	
		This change merely makes putc operate the same as getc when filling
		the buffer before actually attempting to output the buffer.
	
	/Joe
_______________________________________________________________________________
strings.c--ucb			   voder!jeff (Jeff Gilliam)   18 Oct 84   +FIX
	Strings has a minor bug which causes it to ignore the first 32
	bytes of the data segment when run on and executable file and
	*not* given the '-' flag.

    REPEAT BY:
	Try 'strings /usr/ucb/strings'.  You'll see output beginning
	with:
	
	>>>	eley) 3/30/83
		Usage: strings [ -a ] [ -o ] [ -# ] [ file ... ]
		%7D 
		.
		.
		.
	
	Pretty clearly it is missing something at the very beginning.
_______________________________________________________________________________
struct--usr.bin			 mazama!stew (Stewart Levin)   12 Jan 84   +FIX
	Using struct(1) when your login shell is csh(1) fails with
	the message "command trap not found".  One of our people
	managed to lose a source file when they tried this.  (Sorry,
	I don't have any idea how he managed that! it's not struct's
	fault.)

    REPEAT BY:
	Running struct under an interactive csh.

    FIX:
	add the initial line
	
	#! /bin/sh
	
	to the struct shell command file.
_______________________________________________________________________________
struct--usr.bin			    mazama!pete (Peter Mora)   13 Aug 84  
	(1) struct doesnt convert computed goto's into switch blocks as it says it does.
	It completely ignores the computed goto and loses lines after computed goto
	statments.
	(2) struct doesnt convert if else endif blocks to ratfor, it leaves
	the else endif's without {}'s.

    REPEAT BY:
		write(6,*) 'enter 1 or 2'
		read(5,*) i
		goto(1,2) i
	1	write(6,*) 'goto ',i
		goto 3
	2	write(6,*) 'goto ',i
	3	continue
		if(i.eq.1) then
			write(6,*) 'if ',i
		else
			write(6,*) 'if ',i
		endif
		end
_______________________________________________________________________________
su.1--man			jeff@BERKELEY (Jeff Stearns)   10 Dec 83  
	The manual page for su(1) is incomplete.  For example, it does
	not indicate that a command argument may be executed in the style of
	sh -c.

    REPEAT BY:
	N/A.

    FIX:
	Include a description of the -c and -f options (are there others?)
	in /usr/man/man1/su.1.
_______________________________________________________________________________
swapon.c--etc	       decvax!dartlib!steve (Steve Campbell)   28 Nov 83   +FIX
	When one of the syscalls returns -1, the routine hand-generates
	an error message.  One of the arguments to printf is missing,
	resulting in a garbled message being printed on the console.

    REPEAT BY:
	Execute "swapon -a" manually.  Since it was presumably run automatically
	already by /etc/rc, the manual execution will fail, since the
	swap devices will be busy.  One good message and one bad one
	will be printed for each swap device in /etc/fstab.
_______________________________________________________________________________
sys--sys		   dlw@UCBTOPAZ.CC (David L. Wasley)   4 Aug 83   
	There appears to be a bug whereby an interrupted open() will eat
	a file descriptor. This happens in 4.1a (Topaz) and 4.2 (Monet).
	It is a little complex to force, but ... if an open() is hung on
	a tty dev, and is interrupted, it returns -1. That is fine, but
	the file descriptor returned on the next open() will be 1 higher
	that it would have been before the interrupt. After N interrupts
	you get an error return saying "too many files open". The following
	program demonstrates the problem. Put it in the background and
	kill -INT it a number of times.
		David Wasley

    REPEAT BY:
	----
	#include <stdio.h>
	#include <signal.h>
	
	sigint()
	{
		int	fd;
		signal(SIGINT, sigint);
		fprintf(stderr, "interrupt");
		if ((fd = open("/dev/null", 0)) >= 0)
		{
			fprintf(stderr, " (null fd=%d)", fd);
			close(fd);
		}
		fputc('\n', stderr);
	}
	
	char	*dev = "/dev/ttyp7";
	
	main()
	{
		int fd;
		signal(SIGINT, sigint);
		for(;;)
		{
			if ((fd = open(dev, 0)) >= 0)
			{
				fprintf(stderr, "fd=%d\n");
				close(fd);
				sleep(10);	/* otherwise ... */
			}
			else
				perror(dev);
		}
	}
_______________________________________________________________________________
sys--sys			 Doug Kingston <dpk@brl-vgr>   29 Sep 83  
	The 4.1c kernel does not properly clear the exclusive
	open lock if the file that is lock is also being held
	open by another process which has no locks on the file.

    REPEAT BY:
	sleep 1000 < foofile		# hold file open
	
	exclusively open the file and then close it
	try to exclusively open the file again, it
	will either block or return EWOULDBLOCK if you
	asked not to block.  The following program can
	be used to exclusively open the file.
	
	#include <sys/file.h>
	main(argc, argv)
	int	argc;
	char	**argv;
	{
		int	fd;
	
		if((fd = open(argv[1], FRDWR | FNBLOCK | FEXLOCK)) < 0)
			perror(argv[1]);
		else
			close(fd);
	}
_______________________________________________________________________________
sys--sys			   Jeff Mogul <mogul@navajo>   13 Dec 83  
	mysterious file disappearance from iput()
_______________________________________________________________________________
sys--sys				      mayo@ucbrenoir   2 Feb 84   
	Some tty ioctl calls hang if invoked from a procedure that was
	invoked as the result of a SIGCONT signal.

    REPEAT BY:
	/*
	* This program demonstrates a possible problem with Berkeley UNIX.
	* It seems that you cannot do some 'ioctl's inside of a procedure
	* that is invoked in response to a signal.
	*
	* To see the problem, run this program in the forground.  Then stop it
	* using ^Z (or whatever).  Now run it in the background.  It should
	* stop on a 'tty output'.  Everything is fine up to now, but now
	* move the program to the forground.  AH HA!  You are now totally
	* dead in the water.
	*/
	#include <stdio.h>
	#include <signal.h>
	#include <sgtty.h>
	struct sgttyb tx_sgtty;
	sigOnResume()
	{
	   printf("\n<< Resume >>\n");
	   ioctl(fileno(stdout), TIOCSETP, (char *) &tx_sgtty);  /* <-- hangs here */
	   printf("\n<< Done With Resume >>\n");
	}
	main()
	{
	   ioctl(fileno(stdout), TIOCGETP, (char *) &tx_sgtty);
	   signal(SIGCONT, sigOnResume);	
	   while(1)
	   {
	       printf(".");
	       fflush(stdout);
	       sleep(1);
	   }
	}
_______________________________________________________________________________
sys(ipc)--sys		  kilianm%rpi.csnet@csnet-relay.arpa   19 Jun 84  
	I run a program which forks itself into two separate processes.
	I then try to initiate a protocol with a socket by which
	one process will run, then the other, etc. in strict alternation.
	With some combinations of sockets and socket operations, the
	program will run, deadlock, and when the break key is hit (control-C)
	the whole system freezes. The only solution is a complete reboot.
	The interesting point is that if the process is killed from another
	terminal, it termnates normally. I have encountered the problem 
	also in programs which do not deadlock though this is a much rarer
	occurrence.

    REPEAT BY:
	I am including the file which causes this problem. I suggest you
	compile it (i.e., cc killer.c) and run it. It will most likely run
	a bit and then deadlock. Hit control-c to break it. Our system
	reliably halts. (Our system, by the way, is a VAX 11/780 running
	4.2 Berkeley Unix with 4 Megabytes main core.)
	
	File which reliably halts our system:
	
	/***********************************************************************/
	
	#include <stdio.h>
	#include <sys/types.h>
	#include <sys/socket.h>
	#include <errno.h>
	
	extern int errno;
	
	/* Test 10, trying to make sockets work...assume 2 processes. */
	
	
	resource()
	{
	int	i;
	int	s,f;		/* socket identifiers. */
	char	proc[30];	/* accepted socket's name. */
	int	proclen;	/* length of accepted socket's name. */
	
	char	buffer[100];	/* message space. */
	int	cc;		/* return code. */
	
	
	s = socket(AF_UNIX,SOCK_STREAM,PF_UNSPEC);	/* define resource socket. */
	
	cc = bind(s,"  RESOURCE",10);		/* bind name to socket.	   */
	
	listen(s,1);		/* only listen for 1 connection at a time. */
	
	for (;;)
	{
	f = accept(s,proc,&proclen);	/* and accept the connection.	*/
	
	printf("\nAccepted %s",proc);
	fflush(stdout);
	
	/* NOTE TO THE DEBUGGERS!
	
	I believe the following two lines are primarily responsible for the
	problem. I have used a variety of combinations of sockets and they
	have inevitably failed when I try to close one off and possibly
	reopen a connection later.
	*/
	shutdown(f,2);
	close(f);
	
	do
	{
		cc = connect(s,proc,proclen);
	} while (cc < 0);
	
	shutdown(s,2);
	}
	}
	
	process1()
	{
	int	reslen;			/* respective lengths.		*/
	
	int	s,f;				/* our socket number.		*/
	int	cc;
	char	res[30];
	char	buffer[100];
	
	
	s = socket(AF_UNIX, SOCK_STREAM, PF_UNSPEC);	/* define our socket.	*/
	
	bind(s,"  PROCESS1",10);
	
	listen(s,1);
	
	for (;;)
	{
	do
	{
		cc = connect(s,"  RESOURCE",10);
	} while (cc < 0);
	shutdown(s,2);
	
	f = accept(s,res,&reslen);
	
	printf("\nProcess 1 speaking..."); 
	fflush(stdout);
	
	shutdown(f,2);
	close(f);
	}
	}
	
	main()
	{
	
	if (fork() == 0)
	process1();
	else
	resource();
	
	printf("\nWE SHOULD NEVER GET HERE.");
	
	}
	
	/***********************************************************************/
	
	If there is updated documentation on sockets or if I am making a
	fundamental flaw here, please send me any information you can.
	
	Michael Kilian
	(kilianm@rpi)
_______________________________________________________________________________
sys/init_main.c--sys       Mike Braca <mjb%Brown@UDel-Relay>   3 Oct 83    +FIX
	The hard limit for stacksize is initialized to the max data
	size value instead of the max stack size value.

    REPEAT BY:
	Change the maximum data size on your machine. Reboot, log in,
	and look at the hard limit for your stack size. It is wrong.
_______________________________________________________________________________
sys/kern_acct.c,etc/sa.c--sys      watrose!root (Alex White)   2 Dec 83    +FIX
	Accounting records now write times out in seconds, sa still works in
	60ths of seconds.
	Accounting entry ac_mem is incorrect as the kernel divides by
	SECONDS, the integrated memory usage which is in NBPG ticks.

    REPEAT BY:
	Use sa -u to see what's being printed out, its wrong.
_______________________________________________________________________________
sys/kern_clock.c--sys			    trw-unix!gorlick   3 Jun 83    +FIX
	The manual page for getrusage(2) claims that the values
	ru_ixrss, ru_idrss, ru_isrss are in kilbyte*seconds.
	Inspection of sys/kern_clock.c shows that these values
	are kept in kilobyte*ticks where a tick occurs every
	1/HZ seconds.  The kernal call `getrusage' doesn't bother
	to average these values over 1 second intervals.
	
	If you really intend that these values be in kilobyte*seconds
	then it is a mistake to make them integers - they should be
	float.  For quick commands with low memory requirements
	roundoff will always cause an integer value to be zero.

    REPEAT BY:
	Not applicable.

    FIX:
	Change ru_ixrss, ru_idrss, ru_isrss to be float.  Keep
	the values internally as kilobyte*ticks but have `getrusage'
	transform them to kilbyte*seconds.  I agree its important
	to insulate programs from the underlying HZ clock rate.
	
	-Michael Gorlick-
	TRW
	Redondo Beach, CA  90278
_______________________________________________________________________________
sys/kern_clock.c--sys	       guest@ucbarpa (Guest Account)   19 Jun 84   +FIX
	Time-critical code in hardware clock interrupt handler can
	be improved.

    REPEAT BY:
	Examine code in kern_clock.c
_______________________________________________________________________________
sys/kern_clock.c--sys		  Chris Kent <kent@BERKELEY>   9 Jun 83   
	A system configured with only {cpu "VAX730"} in the config file,
	when compiled, results in the symbol IUR being undefined.

    REPEAT BY:
	Take GENERIC, delete the VAX780 and VAX750 lines, config it and
	try to compile it.

    FIX:
	A quick workaround is to define VAX780 and VAX750, but this
	results in a lot of needless code being included.
	
	I haven't investigated it thoroughly, but it seems that adding
	the definition of IUR to vax/mtpr.h, #ifdef'd on VAX730. None
	of the other register definitions seem germane.
_______________________________________________________________________________
sys/kern_descrip.c--sys decvax!uthub!thomson (Brian Thomson)   13 Feb 84   +FIX
	It is possible to close a file descriptor more than once,
	or otherwise use it after it has been closed, and
	possibly after another process has reallocated it or
	reallocated the in-core inode it points to.

    REPEAT BY:
	If you have installed Jeff Mogul's firewall panic in
	closef() [ref. unix-wizards <14552@sri-arpa.UUCP> Dec 12 83]
	you may have already seen this.  If not, then PUT IT IN
	FIRST!!! like so:
	kern_descrip.c, closef(), before
	
		(*fp->f_ops->fo_close)(fp);
	
	insert
		if(fp->f_count < 1)
			panic("closef: f_count < 1");
	
	Then run the following program with the shell 'exec' command,
	such that it is the only process that has your terminal open:
	
	    #include <sys/types.h>
	    #include <setjmp.h>
	    #include <signal.h>
	    #include <sys/ioctl.h>
	
	    jmp_buf jb;
	    int zero;
	
	    gorp() {
		    longjmp(jb, 0);
	    }
	
	    main() {
		    int i;
		    for(i = 0; i < 20; i++)
			    if(i != 1) close(i);
		    setjmp(jb);
		    ioctl(1, TIOCSTART, 0);
		    ioctl(1, TIOCFLUSH, &zero);
		    ioctl(1, TIOCSTOP, 0);
		    write(1, "a", 1);
		    signal(SIGALRM, gorp);
		    alarm(1);
		    close(1);
	    }
	
	If all went well (so to speak) a single 'a' will print on your
	terminal, and your 4.2 system will have paniced.
_______________________________________________________________________________
sys/kern_descrip.c--sys		   salkind@nyu (Lou Salkind)   27 Jan 84   +FIX
	If you try fcntl(fd, F_DUPFD, NOFILE), you get the error
	EMFILE instead of EINVAL.

    REPEAT BY:
	fcntl(fd, F_DUPFD, NOFILE);

    FIX:
	In fcntl, replace the test
		if (i < 0 || i > NOFILE)
	by
		if (i < 0 || i >= NOFILE)
	
	Like I said, a minor nit.
_______________________________________________________________________________
sys/kern_exit.c--sys      rws@mit-bold (Robert W. Scheifler)   17 Nov 83  
	wait() does not check for a zero rusage pointer, and does not
	propagate an EFAULT error that might occur in copying the
	rusage out.

    REPEAT BY:
	Try using an illegal rusage pointer and checking for EFAULT,
	or try having writable text and using a NULL rusage.

    FIX:
	In wait(), the code
		(void) copyout((caddr_t)&ru, (caddr_t)rup, sizeof (struct rusage));
	should be changed to
		if (rup)
			u.u_error = copyout((caddr_t)&ru, (caddr_t)rup, sizeof (struct rusage));
_______________________________________________________________________________
sys/kern_resource.c--sys   Mike Braca <mjb%Brown@UDel-Relay>   27 Sep 83   +FIX
	The csh commands "unlimit datasize" and "unlimit stacksize"
	fail with the "Not owner" error code. This is different from
	what 4.1a did, and I think 4.1a is correct -- the value should
	be set to the maximum allowed instead.

    REPEAT BY:
	Type "unlimit stack" to csh.
_______________________________________________________________________________
sys/kern_sig.c--sys		  sun!shannon (Bill Shannon)   5 Sep 83    +FIX
	Kill can be used with signal 0 to determine if a process exists.
	However, if the process exists but is a different uid than the
	killer it returns ESRCH instead of EPERM.  Returning EPERM makes
	it compatible with System III, as well as being more useful.

    REPEAT BY:
	
	However, if the process exists but is a different uid than the
	killer it returns ESRCH instead of EPERM.  Returning EPERM makes
	it compatible with System III, as well as being more useful.
_______________________________________________________________________________
sys/kern_sig.c--sys		   Mike Muuss <mike@brl-vgr>   13 Jan 84   +FIX
	On 4.1 and earlier UNIX systems, signal handlers had several attributes:
	
	*)  After a signal was caught, the handler was reset to SIG_DFL.
	
	*)  If the process was executing a (kernel) sleep() at "low" priority,
	    and a signal was processed, the system call would abort, returning
	    an error code (-1), with errno = u.u_error = EINTR (interupted
	    system call).
	
	On 4.2 BSD UNIX, these two aspects of signal handling were altered
	(along with some other, nice improvements, which are not germane).
	
	1)  The signal handler remains "installed" until explicitly changed.
	
	2)  System calls which may (kernel) sleep() at "low" priority will
	    be silently restarted after processing an incomming signal.
	    The signal handler will have no idea if this is happening or not.
	
	PROBLEM.
	
	Clearly, programs written for the old style signal interface will have
	a fair amount of difficulty coping with difference #2 above, if they
	depend on signals (especially timer signals) interrupting a system
	call.  Network software which wishes to run timouts around network
	reads will have to longjmp() in the signal handler, rather than
	being able to depend on just returning, with an EINTR to be returned
	from the read/write sys-call that timed out.  Editors and shells
	will have to expect their I/O to be restarted after SIGINT, etc.
	(You would not believe the crud that Berkeley had to do to /bin/sh
	to make it still capable of re-printing $PS1 after a SIGINT (^C, etc).).
	
	Certainly, change #1 is "mostly harmless";  the number of programs
	which will break is minimal -- the timing windows which this change
	fixes were something that no mortal programmer would dare depend on.
	
	However, change #2 is truely problematic:  Certainly, there are advantages
	to the new style signal interface, and programs which are written with
	this style of operation in mind should work out well.  However, no matter
	how hard we try, few of us will be able to afford the luxury of running
	4.2 BSD on *all* our machines.  Those of you planning on purchasing
	a Cray-2 (as we are), will have to contend with System-V UNIX (at least
	to start with).  Many other vendors will be non-4.2 BSD, and it is too
	late to stomp them all out (pitty, no?).  And somehow, those venerable
	old PDP-11s just keep on refusing to quit!
	
	THEREFORE, the problem of program portability rears it's ugly head.
	4.2 people (true believers) will, of course, deisre to import quality
	software from elsewhere ("expensive, yes, extravagant, no"), without
	having to re-write all the signal code.  Others may wish to be able
	to use 4.2 code on their own system ("rotsa-ruck").  Being in the
	former camp, I would like to offer the following solution:

    REPEAT BY:
	Using signals.
_______________________________________________________________________________

              GENERAL INFORMATION ON THE 4.2 BUGLIST FROM MT XINU

          _________________________________________________________________

                           --IMPORTANT DISCLAIMERS--

          Material in this announcement and the  accompanying  reports
          has been edited and organized by MT XINU as a service to the
          UNIX community on a non-profit,  non-commercial  basis.   MT
          XINU  MAKES  NO  WARRANTY,  EXPRESSED  OR IMPLIED, ABOUT THE
          ACCURACY, COMPLETENESS, OR FITNESS FOR USE FOR  ANY  PURPOSE
          OF ANY MATERIAL INCLUDED IN THESE REPORTS.

          MT XINU welcomes comments in writing about the  contents  of
          these reports via uucp or US mail.  MT XINU cannot, however,
          accept telephone calls or enter into telephone conversations
          about this material.

          _________________________________________________________________

          Legal  difficulties  which  have delayed the distribution of
          4.2bsd buglist summaries by MT XINU have been  resolved  and
          three versions of the buglist are now available.

          The current buglist has been derived from reports  submitted
          to  4bsd-bugs@BERKELEY  (not  from reports submitted only to
          net.bugs.4bsd, for example).  Reports  are  integrated  into
          the  buglist as they are received, so that any distributions
          are current to within a week or so.

          Buglists now being distributed are  essentially  "raw".   No
          judgment  has been passed as to whether the submitted bug is
          real or not or whether it has been fixed. Only minimal edit-
          ing  has  been  done  to produce a manageable list.  Reports
          which are complaints (rather than  bug  reports)  have  been
          eliminated;  obscenities  and  content-free flames have been
          eliminated; and duplicates have been combined.  The  result-
          ing collection contains over 500 bugs.


          Three versions of the buglist are now  ready  for  distribu-
          tion:

          2-Liners:
               Two lines per bug, including a concise description, the
               affected   module,  the  submittor.  Approximately  55K
               bytes, it is  being  distributed  to  net.sources  con-
               currently with this announcement.

          All-but-Source:
               All material, except that all but the most inocuous  of
               source  material  has been removed to meet AT&T license
               restrictions.   Nearly  a  mega-byte,  this   will   be
               distributed  to  net.sources in several 50K byte pieces
               later this week.

               A paper listing or mag  tape  is  also  available,  see
               below.

               Please note that local  usenet  size  restrictions  may
               prevent   large   files   from  being  received  and/or
               retransmitted.  MT XINU will not dump this material  on
               the  net  a  second time; if your site has not received
               material of interest to you within a  reasonable  time,
               please send for a paper or tape copy.

          All-with-Source (FOR SOURCE LICENSEES ONLY):

               4.2 licensees who also  have  a  suitable  AT&T  source
               license  can obtain a tape containing all the material,
               including proposed source fixes where such were submit-
               ted.

               Once again, MT XINU has not evaluated, tested or passed
               judgment  on proposed fixes; all we have done is organ-
               ize the collection and eliminate obvious  irrelevancies
               and duplications.


          A free paper copy of the All-but-Source list can be obtained
          by sending mail to:
                  MT XINU
                  739 Allston Way
                  Berkeley CA 94710

                  attn: buglist

          or electronic mail to:

                  ucbvax!mtxinu!buglist

          (Be sure to include your US mail address!)

          For a tape, send a check for $110 or a  purchase  order  for
          $150  to  cover  MT  XINU's costs to the address given above
          (California orders add sales tax).  For the  All-with-Source
          list, mail us a request for the details of license verifica-
          tion at either of the above addresses.