iperf_parse_arguments: Parsing fails due to wrong variable type
Closed this issue · 2 comments
GoogleCodeExporter commented
What steps will reproduce the problem?
Cross compile with arm-xilinx-linux-gnueabi-gcc (Sourcery CodeBench Lite
2012.09-104) 4.7.2 .
What is the expected output? What do you see instead?
Any command line switch results in usage report (usage_long()), even if every
command line switch given is as documented, e.g., iperf -s .
What version of the product are you using? On what operating system?
Version 3.0b5 over Linux (kernel 3.8) compiled for arm-xilinx-linux-gnueabi
cross toolchain (as reported above).
Problem analysis and solution:
The problem is a result of wrong data type given to the local variable "ch" in
iperf_api.c::iperf_parse_arguments().
The original data type for "ch" is "char".
When ch is assigned with return code of getopt_long() it actually assigns/casts
int into char. The result is that when the end of arguments list is reached,
getopt_long() returns (-1), but it is casted to (unsigned) char and becomes
0xFF before compared to the (-1) of the "while" statement (iperf_api.c line
437).
I suspect that this is not seen on other platforms because "char" may default
to "signed char" is some platform but to "unsigned char" in others (there is no
standard for that default...).
Anyway, since getopt_long() returns int, ch should be int, too.
Original issue reported on code.google.com by elazar.r...@gmail.com
on 6 May 2013 at 9:22
GoogleCodeExporter commented
This issue may be related to issue #49.
Still I think that ch should be int, because that's the return code of
getopt_long().
Original comment by elazar.r...@gmail.com
on 6 May 2013 at 12:34
GoogleCodeExporter commented
I agree with your diagnosis.
Original comment by jef.posk...@gmail.com
on 6 May 2013 at 4:42
- Changed state: Fixed