https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90370
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> --- The issue is basically that the C++ Standard Library defines two categories for error numbers known to the implementation: "generic" and "system", where the former is for the POSIX errno values, and the latter is for other error numbers used by the OS for other kinds of errors that aren't covered by a POSIX errno macro (which might be other non-standard EBLAH macros that the OS adds to the POSIX ones, or some totally different error numbers used by the OS, e.g. Windows has its own error numbers unrelated to errno). The question is which category zero belongs to. I think there's a case to be made that although zero isn't an errno value, it's also not an error code used by the OS to mean something different. At least for posix-ish systems, no system API is going to use 0 for something like EPRINTERONFIRE, because that would interfere with normal errno handling in application code. So although zero isn't a POSIX errno value, POSIX does "reserve" the value zero and give it special meaning (it's the value that won't get set to report an error). No posix-ish OS is going to give it a different meaning that clashes with that. I don't think the fact that glibc sometimes sets errno=0 changes that argument, because it's not using 0 for errors, it's still using it to mean "not an error". So although glibc shouldn't set it to zero, it doesn't change the meaning of zero, and it can still be said to be reserved by POSIX, and so belong to the "generic" category. Does that make sense? On the other hand, glibc seeing errno=0 could be considered to be an example of "other error numbers used by the OS" outside of what POSIX says, and so it belongs to "system". So I'm no closer to a decision!
