UUCP PROBLEM ON MICROPORT V/386 3.0e

[Lyndon Nerenberg]

[ Followups directed to comp.bugs.sys5 since this is a generic bug in
  SVR3.1 ... ]

In article <119146 at sun.Eng.Sun.COM> williamt at sun.UUCP (William A. Turnbow) writes:

>	Microport shipped HDB uucp.  The problem was not with debug, but
>was(is) when the first file to be transfered is short.  Now short can
>seemingly be anything under about 120 chars or so, maybe a bit longer,
>though I suspect if it is much over that, it will not get the timing
>error.
[ ... ]
>	The error comes in the statistics gathering section where it tries to
>compute the number of chars transfered per second (cps).

Have you tested your 120 character hypothesis? We ran into this a while
ago, and it turned out to be a divide by zero that occurred when uucico
transfered a zero length (exactly) file. (Who transfers zero length files,
anyway!?!  *I* do, to force polls when I can't directly execute uucico.)

The fix to statlog.c is trivial (if you have source) :

*** statlog.c.old	Tue Aug  8 18:57:35 1989
--- statlog.c	Tue Aug  8 18:58:38 1989
***************
*** 26,32 ****
  	bytes1000 = bytes * 1000;
  	(void) sprintf(text, "%s %lu / %lu.%.3u secs, %lu bytes/sec",
  		direction, bytes, millisecs/1000, millisecs%1000,
! 		bytes1000/millisecs );
  	CDEBUG(4, "%s\n", text);
  	syslog(text);
  }
--- 26,32 ----
  	bytes1000 = bytes * 1000;
  	(void) sprintf(text, "%s %lu / %lu.%.3u secs, %lu bytes/sec",
  		direction, bytes, millisecs/1000, millisecs%1000,
! 		bytes1000 == 0L ? 0L : bytes1000/millisecs );
  	CDEBUG(4, "%s\n", text);
  	syslog(text);
  }

The bug is present on the SVR3.1 porting base tape, so it may be in
a lot of vendor's implementations. I haven't checked to see if it's
present in the 3.2 porting base.
-- 
Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
    {alberta,decwrl,ncc}!atha!lyndon || lyndon at cs.AthabascaU.CA

   CTIX-USERS has moved to:  ctix-users[-request]@cs.AthabascaU.CA