| |||||||||||||
Five Pitfalls of Linux Sockets Programming (developerWorks)Five Pitfalls of Linux Sockets Programming (developerWorks)Posted Sep 21, 2005 12:20 UTC (Wed) by RobSeace (subscriber, #4435)Parent article: Five Pitfalls of Linux Sockets Programming (developerWorks)
> Three classes of return values are possible from the send API function:
Um, no... This is completely wrong... send()/write() will always return
(Log in to post comments)
Five Pitfalls of Linux Sockets Programming (developerWorks) Posted Sep 21, 2005 14:30 UTC (Wed) by hppnq (guest, #14462) [Link] The eh, Six Pitfalls of Linux Sockets Programming eh? ;-)Minor nitpick: if you pass in a length of 0, send(2) and friends will surely return either 0 or -1, but the opposite is not necessarily true: a return value of 0 means "0 bytes sent", which may be either because length == 0 or just because you have no data to send. ;-)
Five Pitfalls of Linux Sockets Programming (developerWorks) Posted Sep 21, 2005 14:38 UTC (Wed) by RobSeace (subscriber, #4435) [Link] There is no other possible scenario where a return value of 0 couldoccur (other than a passed-in length of 0), that I'm aware of... If the socket is blocking, and there is no room in the queue for any more data at all, then send()/write() will block... If the socket is non-blocking, and there is no room in the queue for any more data at all, then send()/write() will return -1 with errno set to EAGAIN... In all other cases, there is room for at least 1 byte of data in the send queue, and hence the return value will be at least 1... I can conceive of no situation, short of passing in a length of 0, where send()/write() could ever possibly return 0...
Five Pitfalls of Linux Sockets Programming (developerWorks) Posted Sep 21, 2005 14:51 UTC (Wed) by hppnq (guest, #14462) [Link] I meant that there is a distinction between the actual length of the data, and the value you pass on to send(2) as the requested number of bytes to send, e.g., send(fd, NULL, 1024, 0).
Five Pitfalls of Linux Sockets Programming (developerWorks) Posted Sep 21, 2005 15:09 UTC (Wed) by RobSeace (subscriber, #4435) [Link] That example I would expect to return -1 with an errno of EFAULT, sincethe NULL pointer is invalid... Alternatively, it might simply crash the app with SIGSEGV... But, I certainly would never expect it to return 0... Really, there is no other notion of "actual length of the data" than the length you pass in to send()/write()... It has no other way of knowing any other length than what you tell it... (Short of running off the end of your valid address space, causing either EFAULT or SIGSEGV...)
Five Pitfalls of Linux Sockets Programming (developerWorks) Posted Sep 21, 2005 15:29 UTC (Wed) by hppnq (guest, #14462) [Link] EFAULT seems appropriate, yes; SIGSEGV would be disappointing.Though, looking up a few send(2) manpages I cannot really conclude that NULL would be an invalid address (I consulted a Solaris manpage before my first comment * bangs head on table * and apparently Solaris doesn't care about EFAULT at all ;-). But it's trivial to find out of course what Linux does in this case, I'll let you know unless you beat me to it. ;-)
Five Pitfalls of Linux Sockets Programming (developerWorks) Posted Sep 21, 2005 16:24 UTC (Wed) by RobSeace (subscriber, #4435) [Link] It does indeed fail with EFAULT on both Linux (2.4.x, at least) and QNX4.2x(the only other system I have access to, at the moment)... On any system where it didn't fail so, I'd expect the seg-fault... It's the only other rational choice...
Five Pitfalls of Linux Sockets Programming (developerWorks) Posted Sep 21, 2005 17:12 UTC (Wed) by hppnq (guest, #14462) [Link] Alright, common sense rules. ;-) Cheers Rob!
|
|||||||||||||