EWOULDBLOCK and EINPROGRESS in process.c

EWOULDBLOCK and EINPROGRESS in process.c

[Eli Zaretskii]

process.c has this fragment after it calls 'connect':

  #ifdef NON_BLOCKING_CONNECT
  #ifdef EINPROGRESS
	if (is_non_blocking_client && xerrno == EINPROGRESS)
	  break;
  #else  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
  #ifdef EWOULDBLOCK
	if (is_non_blocking_client && xerrno == EWOULDBLOCK)
	  break;
  #endif
  #endif
  #endif

Can someone tell why we need that "#else" there?  Suppose there's a
platform that has both values defined, but only returns EWOULDBLOCK
when a non-blocking 'connect' is called -- that platform will fall
through the cracks here.

Is there any problem to replace #else with #endif here?

Re: EWOULDBLOCK and EINPROGRESS in process.c

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> process.c has this fragment after it calls 'connect':
>
>   #ifdef NON_BLOCKING_CONNECT
>   #ifdef EINPROGRESS
> 	if (is_non_blocking_client && xerrno == EINPROGRESS)
> 	  break;
>   #else  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
>   #ifdef EWOULDBLOCK
> 	if (is_non_blocking_client && xerrno == EWOULDBLOCK)
> 	  break;
>   #endif
>   #endif
>   #endif
>
> Can someone tell why we need that "#else" there?  Suppose there's a
> platform that has both values defined, but only returns EWOULDBLOCK
> when a non-blocking 'connect' is called -- that platform will fall
> through the cracks here.

POSIX only defines EINPROGRESS for this situation, so such a platform
would be buggy.

> Is there any problem to replace #else with #endif here?

I don't think it would make any difference in practice.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: EWOULDBLOCK and EINPROGRESS in process.c

[Paul Eggert]

Eli Zaretskii wrote:

> Can someone tell why we need that "#else" there?

The EWOULDBLOCK code is there because Kim Storm heard a rumor that some oddball 
nonblocking 'connect' implementations returned EWOULDBLOCK.  Please see:

https://lists.gnu.org/archive/html/emacs-devel/2002-02/msg00718.html

I also vaguely recall stories that some old Unix platforms did that.  The most 
recent reference I found in a quick Google search was UnixWare 7 Release 7.1.4 
(April 2004):

http://uw714doc.sco.com/en/SDK_netapi/sockC.nonBlockSocks.html

If that documentation is right, the current Emacs code wouldn't work on UnixWare 
7.1.4, not that we care.

Re: EWOULDBLOCK and EINPROGRESS in process.c

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 24 Mar 2015 22:25:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > process.c has this fragment after it calls 'connect':
> >
> >   #ifdef NON_BLOCKING_CONNECT
> >   #ifdef EINPROGRESS
> > 	if (is_non_blocking_client && xerrno == EINPROGRESS)
> > 	  break;
> >   #else  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >   #ifdef EWOULDBLOCK
> > 	if (is_non_blocking_client && xerrno == EWOULDBLOCK)
> > 	  break;
> >   #endif
> >   #endif
> >   #endif
> >
> > Can someone tell why we need that "#else" there?  Suppose there's a
> > platform that has both values defined, but only returns EWOULDBLOCK
> > when a non-blocking 'connect' is called -- that platform will fall
> > through the cracks here.
> 
> POSIX only defines EINPROGRESS for this situation, so such a platform
> would be buggy.
> 
> > Is there any problem to replace #else with #endif here?
> 
> I don't think it would make any difference in practice.

Got it, thanks.

Re: EWOULDBLOCK and EINPROGRESS in process.c

[Eli Zaretskii]

> Date: Tue, 24 Mar 2015 16:42:00 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> The EWOULDBLOCK code is there because Kim Storm heard a rumor that some oddball 
> nonblocking 'connect' implementations returned EWOULDBLOCK.  Please see:
> 
> https://lists.gnu.org/archive/html/emacs-devel/2002-02/msg00718.html
> 
> I also vaguely recall stories that some old Unix platforms did that.  The most 
> recent reference I found in a quick Google search was UnixWare 7 Release 7.1.4 
> (April 2004):
> 
> http://uw714doc.sco.com/en/SDK_netapi/sockC.nonBlockSocks.html
> 
> If that documentation is right, the current Emacs code wouldn't work on UnixWare 
> 7.1.4, not that we care.

Thanks for the references.