3 ms·

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

masklinn 4y ago
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.
- lelanthran 4y ago
  > 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.
aardvark179 4y ago
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.

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.

lelanthran 4y ago
> 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.

aardvark179 4y ago

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.