Hacker News Reader

Comment by actually_a_dog | Hacker News Reader

That’s all documented in the standard though. Why would you access errno any other way?

The main issues with errno are you need to remember to reset it before you enter a context whose failability you care about, so any code which relies on errno must be:

    errno = 0
    // code which may error here
    if(errno) { … }

And that errno is notably not scoped, so the code which may error should only be composed of calls to libc, or code whose interaction with libc you understand perfectly, otherwise you need to save and restore errno around uncontrolled calls.

This is quite verbose, annoying, and error prone.

> The main issues with errno are you need to remember to reset it before you enter a context whose failability you care about, so any code which relies on errno must be:

> errno = 0 > // code which may error here > if(errno) { … }

Which are the functions that set errno, and only errno, on failure?

In practice, you will clear errno once, and then repeatedly check for failure after every call to a libc function.

> And that errno is notably not scoped, so the code which may error should only be composed of calls to libc, or code whose interaction with libc you understand perfectly, otherwise you need to save and restore errno around uncontrolled calls.

I don't understand what this means.

Consider you are trying to do a foreign function call from an interpreted language. You make the call and then want to check errno to see what the error was, but you don't know what precise C calls the runtime may have made in the meantime, or whether it might have reset errno. The only reliable thing to do is to mark library functions explicitly as modifying errno, and storing that somewhere else so that you can reliably retrieve that value.

It's a pain, and if it's not done correctly by everyone then it leaves you with subtle intermittent bugs.

Reply on news.ycombinator.com