Well, this is not true. However, to be fair, most important use case of errno in my work is debugging in horrible code bases, trying to understand what has happened.
The FFI wrappers can restore the previous value of errno after reading the newer value after calling whatever foreign function, thus undoing that side-effect, and nothing other than a signal handler could observe this side-effect in the middle of the FFI wrapper's execution.
Oh, note to self: signal handlers need to restore errno values if they call async-signal-safe functions that can set errno.
