5 ms·

If you don't understand why errno is bad then it'll be hard to explain it. Errno is fine if you're accessing it right after a stdlib function that sets it, bec

by manv1 4y ago

If you don't understand why errno is bad then it'll be hard to explain it. Errno is fine if you're accessing it right after a stdlib function that sets it, because it's the equivalent of a function's error code. Once you get out of that context errno becomes less and less useful and probably shouldn't be used, because without that context you won't know who/what actually set it.

actually_a_dog 4y ago
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.
pjmlp 4y ago
Assuming there is no thread context switch or OS signals between those calls.
- comex 4y ago
  errno is thread-local, so you don’t have to worry about context switches.
  - pjmlp 4y ago
    You won't find that on either ISO C nor POSIX specifications. It only happens to be implemented that way in some environments, as a macro to either thread local or some function call that retrieves the right errno. Still, even that doesn't take care about signal handling.
    - xeeeeeeeeeeenu 4y ago
      Excerpt from C11: "[...] errno which expands to a modifiable lvalue that has type int and thread local storage duration"
      - pjmlp 4y ago
        Still doesn't cover signals, only works if C11 threads are being used (it is all open if OS threads follow the same TLS mechanism), and those C89 and C99 code bases get nothing from it anyway.
        quietbritishjim 4y ago
        In practice it works with major thread implementations even before C11, even though it doesn't say so in the standard. You can't call OS functions from a signal handler so I can't see why signals would matter. Have I missed something?
        cesarb 4y ago

by manv1 4y ago

actually_a_dog 4y ago

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.

pjmlp 4y ago

Assuming there is no thread context switch or OS signals between those calls.

comex 4y ago
errno is thread-local, so you don’t have to worry about context switches.
- pjmlp 4y ago
  You won't find that on either ISO C nor POSIX specifications. It only happens to be implemented that way in some environments, as a macro to either thread local or some function call that retrieves the right errno. Still, even that doesn't take care about signal handling.
  - xeeeeeeeeeeenu 4y ago
    Excerpt from C11: "[...] errno which expands to a modifiable lvalue that has type int and thread local storage duration"
    - pjmlp 4y ago
      Still doesn't cover signals, only works if C11 threads are being used (it is all open if OS threads follow the same TLS mechanism), and those C89 and C99 code bases get nothing from it anyway.
      - quietbritishjim 4y ago
        In practice it works with major thread implementations even before C11, even though it doesn't say so in the standard. You can't call OS functions from a signal handler so I can't see why signals would matter. Have I missed something?
        cesarb 4y ago