huey% adb /usr/lib/libc.so.* _read,4?ia _read: st %o0, [%sp + 0x44] read+4: mov 0x3, %g1 read+8: ta 0x8 read+0xc: bgeu read + 0x40
Nearly every system call returns a single value, ranging from a pointer
or an address, such as from
to the size of a data transfer from
write(), to a standard system type like a UID returned by
getuid(). System calls that return integers often use
negative return values to flag a failure, but this rule doesn't apply
to calls that return addresses, which are usually set to NULL if the
call fails. Simple, inconsistent indicators of success or failure don't
give you (and your process) enough information to determine what went
wrong and how to repair the situation, so the system call return value
is supplemented by the error number, or errno value.
If an exception is encountered while processing the system call,
errno is set to one of the values in /usr/include/sys/errno.h.
A successful call sets errno to zero. Most applications include the
errno.h header file, containing the possible values of errno.
extern int errno; in your code, and it is
accessible as an integer variable.
In theory, your code should check the value of errno after each
system call, including those that should "never" fail like
close(), because these system calls can report
failures deferred from other requests -- a topic we'll visit later. Of
course, not all code does such paranoid checking, and you can't modify
commercial applications to make them fit your quality standards ex
post facto. So, how do you start tracking down a user issue when
all you have is an error message?
The system call return value
is supplemented by the error number,
or errno value.
The first thing to do is to become familiar with the various kinds of
errors reported back through the errno mechanism. Your best source of
information is the introduction to section 2 of the manual pages: