4 ms·

> `errno` is another relic that needs to die yesterday. ok, i will bite: what is the problem with it ?

ForkMeOnTinder 3y ago
It's global state for a local condition. Linus Torvalds on errno: https://yarchive.net/comp/linux/errno.html https://yarchive.net/comp/linux/errno.html
- signa11 3y ago
  > ... Linus Torvalds on errno: https://yarchive.net/comp/linux/errno.html https://yarchive.net/comp/linux/errno.html yes, he argues against its usage in the KERNEL.
  - Cloudef 3y ago
    But his argument stands even outside the kernel. Errno is awful, similar to locale APIs.
burntsushi 3y ago
Shared global (well, thread local) mutable state. As for why shared global mutable state is (generally) bad, see: https://softwareengineering.stackexchange.com/questions/148108/why-is-global-state-so-evil https://softwareengineering.stackexchange.com/questions/1481... `man 3 errno` on my Linux system even has a note calling out a common failure pattern. Can you spot the problem? if (somecall() == -1) { printf("somecall() failed\n"); if (errno == ...) { ... } }
- j16sdiz 3y ago
  What's the alternative? Returning a"Result" struct doubles the size. This is one less register to use. Exception handling is even more invasive. They are great for high(-er) level language, but less prefect on lower level where performance is critical. EDIT: Linux kernel use negative return value for error. It's good and efficient when it work. But it is not always an option when you need the full register width
  - bdd8f1df777b 3y ago
    Most of the POSIX functions that use errno for error signaling simply return 0 for success and -1 for error. They could have returned errno directly.
    - tedunangst 3y ago
      What about the rest?
      - deleted 3y ago
        [deleted]
      - bdd8f1df777b 3y ago
        Put the original return value in a pointer argument, and return errno (or -errno).
    - ronsor 3y ago
      Last I checked, the Linux kernel ABI does return -errno for errors. Then libc mangles that all up.
    - wahern 3y ago
      Some newer POSIX APIs, such as pthreads, do return the error this way. But many legacy APIs, such as dup or read, use the positive integer space, thus the negation pattern you often see in syscalls. Notably, POSIX guarantees <errno.h> values to be positive integers.
      - bdd8f1df777b 3y ago
        `dup` and `read` returns -1 on error and set the `errno` variable. If they were redesigned, they should just return `-errno` on failure.
  - burntsushi 3y ago
    There are a lot of alternatives, and it's not clear why the ones you've suggested are inappropriate. You've listed some perceived costs, but I don't see why those costs are greater than the ones paid by the status quo. Linux even shows you a path, yet you reject it for reasons that don't seem compelling to me.
- charcircuit 3y ago
  There are 2 errno mistakes in that snippet since there is no way to know who set errno.
- signa11 3y ago
  regarding your snippet: if (somecall() == -1) { printf("somecall() failed\n"); if (errno == ...) { ... } } sure, the issue is that `somecall(...)` might have altered `errno` through 'acts-of-omission-or-comission' :o) fwiw, posix has updated its definition to pretty much say that 'value of errno in one thread is not affected by assignments to it by another'. this has been the case since at least a decade-and-a-half (iirc), which in internet years would positively be in the pleistocenic era :o) so, i am not sure i really appreciate 'the shared-global-mutable-state' argument above. thanks !
  - SkiFire13 3y ago
    The problem in that snippet is that `printf` could have altered the `errno` set by `somecall`, and that's only thanks to it being shared-global-mutable-state. You not realizing that was possible makes for a great example of why shared-mutable-global-state is hard to reason about.
    - signa11 3y ago
      crap, i definitely meant to write `printf(...)` there ! my typical usage for such scenarios i.e. when i know that callee might alter errno etc. is to int save_errno = errno; do_foo(...); if (errno == ...) { ... } wrapping libc into something that (maybe) does better seems like such a sisyphean task to me.
      - burntsushi 3y ago
        This thread isn't talking about how to fix the errno problem generally. It's talking about the existence of a problem in the first place. Fixing it would be a whole different can of worms, and indeed, sisyphean sounds about right. Notice how this entire thread was started by someone asking why errno was problematic. This is just about understanding.
        signa11 3y ago
        > Notice how this entire thread was started by someone asking why errno was problematic. This is just about understanding. yes, you are absolutely right. this is just about understanding and how easy it is to miss what is hidden just one-level away.
yxhuvud 3y ago
The most obvious way it is wrong is that it is archaic. There is simply no reason to ever pass return values in hidden state. Just use return values damnit.

It's global state for a local condition. Linus Torvalds on errno: https://yarchive.net/comp/linux/errno.html https://yarchive.net/comp/linux/errno.html

signa11 3y ago
> ... Linus Torvalds on errno: https://yarchive.net/comp/linux/errno.html https://yarchive.net/comp/linux/errno.html yes, he argues against its usage in the KERNEL.
- Cloudef 3y ago
  But his argument stands even outside the kernel. Errno is awful, similar to locale APIs.

burntsushi 3y ago

Shared global (well, thread local) mutable state. As for why shared global mutable state is (generally) bad, see: https://softwareengineering.stackexchange.com/questions/148108/why-is-global-state-so-evil https://softwareengineering.stackexchange.com/questions/1481... `man 3 errno` on my Linux system even has a note calling out a common failure pattern. Can you spot the problem? if (somecall() == -1) { printf("somecall() failed\n"); if (errno == ...) { ... } }

j16sdiz 3y ago
What's the alternative? Returning a"Result" struct doubles the size. This is one less register to use. Exception handling is even more invasive. They are great for high(-er) level language, but less prefect on lower level where performance is critical. EDIT: Linux kernel use negative return value for error. It's good and efficient when it work. But it is not always an option when you need the full register width
- bdd8f1df777b 3y ago
  Most of the POSIX functions that use errno for error signaling simply return 0 for success and -1 for error. They could have returned errno directly.
  - tedunangst 3y ago
    What about the rest?
    - deleted 3y ago
      [deleted]
    - bdd8f1df777b 3y ago
      Put the original return value in a pointer argument, and return errno (or -errno).
  - ronsor 3y ago
    Last I checked, the Linux kernel ABI does return -errno for errors. Then libc mangles that all up.
  - wahern 3y ago
    Some newer POSIX APIs, such as pthreads, do return the error this way. But many legacy APIs, such as dup or read, use the positive integer space, thus the negation pattern you often see in syscalls. Notably, POSIX guarantees <errno.h> values to be positive integers.
    - bdd8f1df777b 3y ago
      `dup` and `read` returns -1 on error and set the `errno` variable. If they were redesigned, they should just return `-errno` on failure.
- burntsushi 3y ago
  There are a lot of alternatives, and it's not clear why the ones you've suggested are inappropriate. You've listed some perceived costs, but I don't see why those costs are greater than the ones paid by the status quo. Linux even shows you a path, yet you reject it for reasons that don't seem compelling to me.
charcircuit 3y ago
There are 2 errno mistakes in that snippet since there is no way to know who set errno.
signa11 3y ago
regarding your snippet: if (somecall() == -1) { printf("somecall() failed\n"); if (errno == ...) { ... } } sure, the issue is that `somecall(...)` might have altered `errno` through 'acts-of-omission-or-comission' :o) fwiw, posix has updated its definition to pretty much say that 'value of errno in one thread is not affected by assignments to it by another'. this has been the case since at least a decade-and-a-half (iirc), which in internet years would positively be in the pleistocenic era :o) so, i am not sure i really appreciate 'the shared-global-mutable-state' argument above. thanks !
- SkiFire13 3y ago
  The problem in that snippet is that `printf` could have altered the `errno` set by `somecall`, and that's only thanks to it being shared-global-mutable-state. You not realizing that was possible makes for a great example of why shared-mutable-global-state is hard to reason about.
  - signa11 3y ago
    crap, i definitely meant to write `printf(...)` there ! my typical usage for such scenarios i.e. when i know that callee might alter errno etc. is to int save_errno = errno; do_foo(...); if (errno == ...) { ... } wrapping libc into something that (maybe) does better seems like such a sisyphean task to me.
    - burntsushi 3y ago
      This thread isn't talking about how to fix the errno problem generally. It's talking about the existence of a problem in the first place. Fixing it would be a whole different can of worms, and indeed, sisyphean sounds about right. Notice how this entire thread was started by someone asking why errno was problematic. This is just about understanding.
      - signa11 3y ago
        > Notice how this entire thread was started by someone asking why errno was problematic. This is just about understanding. yes, you are absolutely right. this is just about understanding and how easy it is to miss what is hidden just one-level away.

yxhuvud 3y ago

The most obvious way it is wrong is that it is archaic. There is simply no reason to ever pass return values in hidden state. Just use return values damnit.