iperf_parse_arguments: Parsing fails due to wrong variable type

[GoogleCodeExporter]

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]

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]

I agree with your diagnosis.

Original comment by jef.posk...@gmail.com on 6 May 2013 at 4:42

• Changed state: Fixed