2 ms·

regarding your snippet: if (somecall() == -1) { printf("somecall() failed\n"); if (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 !

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.
burntsushi 3y ago
I specifically mentioned thread local. The problems of shared global mutable state aren't limited to multi threaded environments.

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.

burntsushi 3y ago

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