aboutsummaryrefslogtreecommitdiffstats
path: root/xcomp
diff options
context:
space:
mode:
authorSteve Vinoski <[email protected]>2010-05-12 23:24:50 -0400
committerRaimo Niskanen <[email protected]>2010-05-27 12:04:00 +0200
commita75105b90281b61158b3570e3120317a084b07a4 (patch)
tree94ccb1ee9a8f897ff513cae62f299e12d86e308f /xcomp
parent18a59bf3b0c12432783eccb3e847999f9fbee6cf (diff)
downloadotp-a75105b90281b61158b3570e3120317a084b07a4.tar.gz
otp-a75105b90281b61158b3570e3120317a084b07a4.tar.bz2
otp-a75105b90281b61158b3570e3120317a084b07a4.zip
use macro to portably test for socket system call errors
On some combinations of Montavista Linux running on Cavium Octeon chips, some socket-related system calls erroneously return negative numbers other than -1 to indicate errors, but inet_drv.c specifically compares against -1 to test for errors. The result is that beam dumps core due to the code treating these negative numbers as success indicators, as counts/offsets of bytes written, etc. thereby corrupting its own internal data structures. To fix this, introduce a portability macro to test the result of socket system calls. The test remains unchanged on Windows but for other platforms the macro considers all return values that are less than zero to be errors. Though POSIX specifies that errors from these system calls are indicated by a return value of -1, treating all negative return values as errors is also safe, as described in detail below. In networking programming, treating all negative return values from system calls as errors is very common practice -- see the examples in W. Richard Stevens's popular and highly lauded network programming books, for example. For system calls that return 0 to indicate success, treating all negative numbers as errors is safe because only 0 is specified to indicate success. These include: getsockname getpeername getsockopt gethostname bind listen connect close shutdown Likewise, for system calls that return non-negative numbers to indicate success, treating all negative numbers as errors is also safe. These functions typically return signed integers of type ssize_t, and they treat any parameters of type size_t that cannot fit within the ssize_t return value, such as numbers of bytes to read or write, as errors (specifically EINVAL). For example, in the "ERRORS" section of the man page for writev from several varieties of Linux, it states that EINVAL is returned when the total length of the I/O is more than can be expressed by the ssize_t return value. These calls include: recv recvfrom recvmsg writev send sendto sendmsg Finaly, the socket() system call is also similar to these in that it returns a signed type (int) with all non-negative return values indicating success, so treating all negative return values as errors is safe.
Diffstat (limited to 'xcomp')
0 files changed, 0 insertions, 0 deletions