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.

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

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

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

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.

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.

What about the rest?

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

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.

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.