bug#22789: 25.1.50; In last master build https connections stop working

[Alain Schneble <a.s@realize.ch>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alain Schneble <a.s@realize.ch>
>> Date: Sun, 28 Feb 2016 00:49:25 +0100
>> Cc: "José L. Doménech"
>> 	<j_l_domenech@yahoo.com>, 22789@debbugs.gnu.org
>> 
>> Now, if I do...
>> 
>> 	  if (errno == 0)
>> 	    errno = EAGAIN;
>> 
>> ...just after the call to set_errno above, guess what: It seems to work!
>
> This must be conditioned on something that requires EAGAIN.  Otherwise
> overriding the errno of zero sounds like a bad idea to me.

This was just a quick try, to better understand the behavior.  Not a
proposed solution.  Excuse me for not being precise.

> Why does the nchars == SOCKET_ERROR happen here at all, if winsock
> returns with an error of zero?  Isn't that strange?

Exactly, this was what I meant in the part you elided:

Alain Schneble <a.s@realize.ch> writes:

> At least for me, it will be an exercise for tomorrow to find the reason
> why pfn_WSAGetLastError returns 0 in this case.

I just had some time to investigate it further.  The WSAGetLastError
gets overridden in the call to pfn_ioctlsocket.  That's why errno is 0.

If I swap the order of the if statements in sys_write to look as
follows, then the reason for the SOCKET_ERROR is revealed:

      if (nchars == SOCKET_ERROR)
        {
	  DebPrint (("sys_write.send failed with error %d on socket %ld\n",
		     pfn_WSAGetLastError (), SOCK_HANDLE (fd)));
	  set_errno ();
	}

      /* Set the socket back to non-blocking if it was before,
	 for other operations that support it.  */
      if (fd_info[fd].flags & FILE_NDELAY)
	{
	  printf ("reset file_ndelay");
	  nblock = 1;
	  pfn_ioctlsocket (SOCK_HANDLE (fd), FIONBIO, &nblock);
	}

=> WSAENOTCONN (10057): Socket is not connected.  So that's the prove it
accesses the socket too early.

Alas, even though it seems to help at least for the test code I tried,
turning WSAENOTCONN into EAGAIN seems wrong after all.  It shouldn't try
to write to the socket before it is connected at all...(?)  Also the
code "wraps" pfn_send and turns it into a blocking call.  Not sure what
the implications are...

Nevertheless, don't you think the error handling in this code section is
not very elaborate and switching the order as shown above might be
better anyway?  sys_write is primarily about writing, not about
switching from non-blocking to blocking and back again...  Or shall it
somehow aggregate possible errors of both calls (pfn_send and
pfn_ioctlsocket)?