diff options
author | Steve Vinoski <[email protected]> | 2010-05-12 23:24:50 -0400 |
---|---|---|
committer | Raimo Niskanen <[email protected]> | 2010-05-27 12:04:00 +0200 |
commit | a75105b90281b61158b3570e3120317a084b07a4 (patch) | |
tree | 94ccb1ee9a8f897ff513cae62f299e12d86e308f /system/doc/oam | |
parent | 18a59bf3b0c12432783eccb3e847999f9fbee6cf (diff) | |
download | otp-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 'system/doc/oam')
0 files changed, 0 insertions, 0 deletions