home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.protocols.tcp-ip      TCP and IP network protocols.      14,669 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 12,907 of 14,669   
   Dan Lanciani to reppisch   
   Re: maximum allowable buffer size for se   
   03 Jun 09 04:55:28   
   
   From: ddl@danlan.*com   
      
   In article , spam@reppisch.de (reppisch) writes:   
   | Dan Lanciani schrieb:   
   | > In article , spam@reppisch.de (reppisch) writes:   
   | > | Hi,   
   | > | >   
   | > | > It might be errno (which might be defined in some tricky way) or   
   something   
   | > | > like WSAGetLastError() on Windows.   
   | > | >   
   | > | i found out errno is no longer a extern int when using -D_REENTRANT.   
   | > | It's replaced by a Macro/function call/tls-storage variable.   
   | > | so you suggest using errno?   
   | >   
   | > Yes.  getsockopt(...SO_ERROR...) is not going to do what you want.   
   | >   
   | > 				Dan Lanciani   
   | > 				ddl@danlan.*com   
   | Ok,   
   |   
   | so why is it there?   
      
   Mainly it was used to hold an error status that arises asynchronously   
   to any API function and would otherwise be lost.  That does not mean   
   that it never holds the same error status that is returned synchronously   
   in errno, but for some such errors it wouldn't make sense (e.g., ENOTSOCK,   
   EBADF) and for some it would conflict with other usage (EWOULDBLOCK) and   
   for some it migh be possible but isn't aesthetic (e.g., EFAULT).  It   
   worries me a little that the only reason I'm comfortable with the usage   
   is that I spent so much time with at least one implementation's source   
   code...   
      
   				Dan Lanciani   
   				ddl@danlan.*com   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca