Xref: utzoo comp.sys.next:18458 comp.bugs.4bsd:1821 comp.mail.uucp:6776
Newsgroups: comp.sys.next,comp.bugs.4bsd,comp.mail.uucp
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!shaman!jiro
From: jiro@shaman.com (Jiro Nakamura)
Subject: Bug in uuq on NeXT -- cannot change baudrate
Message-ID: <1991Jun4.202736.3158@shaman.com>
Sender: jiro@shaman.com (Jiro Nakamura)
Organization: The Shaman Group
Date: Tue, 4 Jun 1991 20:27:36 GMT

Hiya -
	This may be a general bug report. Has anyone noticed that they
cannot change the baudrate for uuq:
	shaman> /usr/bin/uuq -b2400 -l | more
	batcomp: 1 job, 391 bytes, 0.0 minutes (@ effective baudrate of 357913941)


	As you can see, the baudrate becomes bogus. This may only occur
on NeXT's. I have verified this bug for Systems 1.0, 1.0a, 2.0, and 2.1.

	The bug is caused by one line in uuq.c (lines 130-132):

               case 'b':
                        baudrate = atof(optarg);
                        break;


	That atof() should be an atoi(). At least on a NeXT, the atof
is incorrectly reading the value of the input, as you can see above.
The variable baudrate is float, but it will be cast properly. Changing
atof() to atoi() fixes the bug and will yield the correct baud rate. Note
that baudrate gets multiplied by a magic number to yield approximate
throughput.
	Now, how to fix this bug? Since NeXT does not provide source to
everyone, I will upload a package to nova.cc.purdue.edu. This
will contain the source and binaries to the gnu version of uuq (which
I snarfed off bu.edu, in case you're interested). I didn't include
the whole package because I'm not finished porting everything. Note
that this is not a complete port. :-(


	- Jiro Nakamura
	jiro@shaman.com