Hacker News Reader

Comment by signa11 | Hacker News Reader

> `errno` is another relic that needs to die yesterday.

ok, i will bite: what is the problem with it ?

Shared global (well, thread local) mutable state.

As for why shared global mutable state is (generally) bad, see: 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 == ...) { ... }
           }

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

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.

What about the rest?

Put the original return value in a pointer argument, and return errno (or -errno).

Last I checked, the Linux kernel ABI does return -errno for errors. Then libc mangles that all up.

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.

`dup` and `read` returns -1 on error and set the `errno` variable. If they were redesigned, they should just return `-errno` on failure.

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.

> Returning a"Result" struct doubles the size. This is one less register to use.

One less register right before and after returns doesn't sound like a big problem, especially with 16+ registers.

You are saving one register at the cost of having a thread local variable that is visible to signal handlers, so none of its uses can be optimized away. Which results in things like gcc having to decorate every math instruction with code to set errno on the off chance that someone somewhere might read it (no one ever does).

The performance cost of having otherwise pure functions clobber global mutable memory defeating many optimization passes, is way higher than clobbering another register for the result.

There are 2 errno mistakes in that snippet since there is no way to know who set errno.

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 !

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.

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.

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.

> 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.

I specifically mentioned thread local. The problems of shared global mutable state aren't limited to multi threaded environments.

It's global state for a local condition.

Linus Torvalds on errno: https://yarchive.net/comp/linux/errno.html

> ... Linus Torvalds on errno: https://yarchive.net/comp/linux/errno.html

yes, he argues against its usage in the KERNEL.

But his argument stands even outside the kernel. Errno is awful, similar to locale APIs.

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.

Reply on news.ycombinator.com