Can anyone explain this obscure behaviour?

I am trying to write a port scanner for a security course. I decided to write it in C on Linux as I've never done anything networking related outside of Java. I'm using GCC 4.4.5 on Ubuntu 10.10. I've got a main function that parses arguments and then calls a scan function with the resultant variables. Here is my complete program: http://p开发者_Go百科astebin.com/DHU7SEQR

The problem I'm having is that it doesn't work properly (it reports that all ports are open) unless I print out the variables received from the user before calling the function (or rearrange the order of the parameters passed to the executable), which makes absolutely no sense to me. Note the line that is commented out (150), leaving this line commented out and compiling with the command

gcc scanner.c -o scanner

and then running the program with

./scanner -a 127.0.0.1 -b 0 -e 1000 -t 1000

results in it reporting all ports to be open. However, uncommenting that line (ie, printing out all the variables before calling the function), results in the ports' status being reported correctly. Rearranging the order of the parameters to

./scanner -b 0 -e 1000 -t 1000 -a 127.0.0.1

seems to work as well, as does adding a printf statement to each case block (even when not printing the variables themselves).

$ valgrind ./scanner -a 127.0.0.1 -b 0 -e 1000 -t 1000
==3800== Memcheck, a memory error detector
==3800== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3800== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==3800== Command: ./scanner -a 127.0.0.1 -b 0 -e 1000 -t 1000
==3800== 
==3800== Syscall param socketcall.getsockopt(optlen) points to uninitialised byte(s)
==3800==    at 0x4F15DCA: getsockopt (syscall-template.S:82)
==3800==    by 0x400BC5: scan (scanner.c:83)
==3800==    by 0x400DBB: main (scanner.c:152)
==3800==  Address 0x7ff000330 is on thread 1's stack
==3800== 
==3800== Syscall param socketcall.getsockopt(optlen_out) points to uninitialised byte(s)
==3800==    at 0x4F15DCA: getsockopt (syscall-template.S:82)
==3800==    by 0x400BC5: scan (scanner.c:83)
==3800==    by 0x400DBB: main (scanner.c:152)
==3800==  Address 0x7ff000330 is on thread 1's stack
==3800== 

Check the manpage for getsockopt(2).

For getsock‐ opt(), optlen is a value-result argument, initially containing the size of the buffer pointed to by optval, and modified on return to indicate the actual size of the value returned. If no option value is to be supplied or returned, optval may be NULL."

So you need to initialize len on line 82.

Note: There might be other problems with the code.