[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR

From: Ken Brown
Subject: bug#23615: 25.1.50; Which platforms can safely use getsockopt(,,SO_ERROR,,)?
Date: Sat, 28 May 2016 13:18:27 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0

On 5/28/2016 8:57 AM, Eli Zaretskii wrote:
From: Ken Brown <address@hidden>

Test program attached.  It simulates the situation of bug 23606 (before
the bug was fixed).  Here's what happens on Cygwin:

$ gcc -o socket_test socket_test.c

$ ./socket_test.exe
Server listening on port 50176.
Attempting client connection...failure: Connection refused.

With MinGW, I get this instead:

  Server listening on port 2213.
  Attempting client connection...success.

Do we have to have a failure in this case?  Or is the above a valid

It's a valid outcome. I think the reason the connection is refused on Cygwin (and apparently on RHEL 7.2) is that the first addrinfo structure returned by getaddrinfo has an IPv6 address. There's no reason to expect this to happen on all platforms.

Of course, I needed to hack the code quite a lot to get it compile on
MS-Windows; the result is attached below.  Maybe I broke the code
while doing that?

No, you didn't. I get the same results as before with your version, after fixing a couple of typos that don't affect the MinGW build. (You forgot a semicolon at the end of line 41, and you misspelled "strerror" in line 126.)

(I don't think calling 'connect' after 'listen' is supposed to work;
on Windows it predictably fails with EINVAL, as documented on MSDN.)

I think on Posix systems it fails with EISCONN. I put the call in because it's done in the code in process.c that I was imitating, but omitting it as you did is fine also.

Thanks for testing.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]