Unless you're hacking on glibc, you really shouldn't be digging around in the system include files. Nevertheless, doing some googling around I learned this:
k5054@localhost]$ cpp -include stdlib.h -dM /dev/null | grep -E 'define __(THROW|LEAF)\>'
#define __LEAF , __leaf__
#define __THROW __attribute__ ((__nothrow__ __LEAF))
[k5054@localhost]$
That means that the __THROW notation adds the attributes nothrow and leaf to the definition of the function. You can read up on them here:[Function Attributes - Using the GNU Compiler Collection (GCC)](https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html) Surely by now you know how to handle libc errors:
#include
#include
int ret = socket(foo, bar, baz); // socket() returns -1 on error and sets global var errno
if(ret == -1 ) {
switch (errno) {
case EACCES:
// handle EACCES issue
break;
// etc.
default:
// print out the text associated with the error using strerror()
std::cerr << "socket() returned error " << strerror(errno) << '\n';
}
}
Note: It is perfectly possible for errno to be set by a system call, even when the system call is successful. That can happen when the system call itself makes another system call, which sets errno. I ran into this not so long ago with code like:
errno = 0;
ret = somefn(blah, blah, blah);
if (errno) {
// do stuff
}
In this case somefn() called otherfn() to do its work. otherfn() failed, setting errno in the process, and then somfn handled the error, and perhaps called anotherfn() which succeded, but did not set errno back to zero. Moral of the story: you need to check if your system call returned an error (normally -1, but not neccesarily), and then check the value of errno.
Keep Calm and Carry On
