ratproxy does not fully initialize sockaddr_in before calling bind(2)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compile ratproxy 1.50-beta on Mac OS X version 10.5.3.
2. Run with ./ratproxy.

What is the expected output? What do you see instead?

  I expect ratproxy to start running on port 8080/tcp.  Instead I get:

    SYSTEM ERROR : cannot bind to port [listen_loop(), ratproxy.c:1610]
         Message : Can't assign requested address

What version of the product are you using? On what operating system?

    ratproxy 1.50-beta; Mac OS X version 10.5.3.

Please provide any additional information below.

 It seems to be an issue of not properly initializing the sockaddr_in
 structure before calling bind(2).  This patch fixes this problem for
 me:

--- ratproxy.c.orig 2008-07-03 11:19:23.000000000 -0700
+++ ratproxy.c  2008-07-03 11:19:29.000000000 -0700
@@ -1594,6 +1594,7 @@
   if (setsockopt(lsock, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(_s32)) == -1) 
     pfatal("cannot setsockopt()");  

+  memset(&saddr, 0, sizeof saddr);
   saddr.sin_family      = AF_INET;

   if (!use_any) {

Original issue reported on code.google.com by matthew....@gmail.com on 3 Jul 2008 at 6:21

[GoogleCodeExporter]

This was already fixed in 1.51. 

[ It is an interesting behavior, by the way - MacOS X apparently requires 
sin_zero
(the only part not initialized) to be zeroed out for loopback binds, but not for
0.0.0.0 binds. Huh? ]

Original comment by lcam...@gmail.com on 4 Jul 2008 at 7:06

• Changed state: Duplicate

[GoogleCodeExporter]

Oops, you're right.  Sorry, I just grabbed the 1.50 tarball from a link 
elsewhere and
assumed it was the latest.

1.51 works fine for me without any patching.

Original comment by matthew....@gmail.com on 4 Jul 2008 at 7:27