strerror_r -- GNU version

[Florian Weimer]

* Chris Hall:

> I note that for all known error numbers, the current implementation of
> GNU strerror_r() returns a pointer to a constant string (and not the
> supplied buffer).
>
> So I can use GNU strerror_r() to distinguish known error numbers from
> unknown (or invalid) ones.

That's really fringe behavior and probably not a good choice.

> But to do so I am depending on an undocumented feature of the
> implementation (of a non-standard function) -- which is a worry :-(
>
> I note that the POSIX (XSI) strerror_r() may return EINVAL for invalid
> error numbers.  And invalid appears to include unknown numbers.  But
> that cannot be relied on, either.
>
> Is there a good standard/portable way to distinguish known error numbers ?

Not really.  The Linux kernel sometimes leaks error numbers in the 5xx
range that do not have E* constants in the UAPI headers.  Software like
Berkeley DB also use its own errno-like constants in a separate numeric
range.

We discussed a related question in the context of C++:

  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90370>

> FWIW: I wish there was a portable way to map error numbers to their
> macro names (or at least a preferred macro name), which could double
> as a way to discover whether an error number is known or not.

Yes, that's a reasonable request, given that these macro names are
architecture-independent and not subject to localization.  I've written
several implementations of that functionality outside glibc.  Having
something similar for signal constants might make sense, too.

However, I caution against using this to determine whether an error
number is invalid or not.

Thanks,
Florian