Hi tech@,
I tried the code from radioctl(1) on a test program, since I don't have
a radio tuner, and cannot reproduce this problem, nevertheless like
Douglas mentioned below shouldn't strtod(3) be used instead of atof(3)
since it has overflow/underflow checks for free?
Also are there any merits in changing the rest of tree looking for
atoi(3) and atol(3)? Not worth the time? Not enough portable?
Index: radioctl.c
===================================================================
RCS file: /cvs/src/usr.bin/radioctl/radioctl.c,v
retrieving revision 1.19
diff -u -p -u -r1.19 radioctl.c
--- radioctl.c 21 Dec 2013 06:54:53 -0000 1.19
+++ radioctl.c 9 Nov 2015 20:45:25 -0000
@@ -389,7 +389,7 @@ str_to_int(char *str, int optval)
return VALUE_NONE;
if (optval == OPTION_FREQUENCY)
- val = (int)(1000 * atof(str));
+ val = (int)(1000 * strtod(str, (char **)NULL));
else
val = (int)strtol(str, (char **)NULL, 10);
Best regards,
Ricardo Mestre
On 07/11/2015 22:02, Douglas Maus wrote:
on my system
# radioctl frequency=99.3
frequency: 99.25MHz -> 99.25MHz
Not a big deal, but frequencies of 99.3 being interpreted as slightly lower
at 99.25
is not ideal for some applications
This happens for other floats ending in '.3', '.1', etc
I tracked this down in radioctl.c to the function str_to_int():
if (optval == OPTION_FREQUENCY)
val = (int)(1000 * atof(str))
with the str="99.3", the integer val generated is 99299
because of integer truncation with the cast
a version that generates more expected values for me is something like:
val = lrint(1000*strtod(str, NULL));
at the cost of lrint() requiring the <math.h> header, and math library
and strtod() instead of the (deprecated) atof()
just FYI if someone wanted to update it
