jiro@shaman.com (Jiro Nakamura) (06/05/91)
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.comromain@salt.pyramid.com (Romain Kang) (06/06/91)
In <1991Jun4.202736.3158@shaman.com> jiro@shaman.com (Jiro Nakamura) writes: | The bug is caused by one line in uuq.c (lines 130-132): | case 'b': | baudrate = atof(optarg); | break; The original 4.3 uuq source declared atof() as float. It's really a double, but VAXen don't care. It was fixed in 4.3-tahoe. Clearly, using atoi() works also. Lou Salkind may have automatically used atof() because (if I recall correctly) he was a graduate physics student at the time. -- ``!!x09 dimaryP a fo edisni deppart m'I !pleH'' ``oNhwre eenraa sab dsab iegnt arppdei n aAV X117/05!!''