* strerror_r -- GNU version
@ 2020-01-04 13:59 Chris Hall
2020-01-08 13:27 ` Florian Weimer
0 siblings, 1 reply; 2+ messages in thread
From: Chris Hall @ 2020-01-04 13:59 UTC (permalink / raw)
To: libc-help
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.
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 ?
Inspection of the (recent) glibc implementation of POSIX (XSI)
strerror_r() tells me that (a) it does return EINVAL for unknown errors,
and (b) it uses GNU strerror_r() and checks the return address to detect
known/unknown errors.
On a you-know-and-I-know-it-works basis I could depend on the same
trick, if _GNU_SOURCE... But I guess I have to expect to be bitten in
the backside at some time in the future ?
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.
Chris
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: strerror_r -- GNU version
2020-01-04 13:59 strerror_r -- GNU version Chris Hall
@ 2020-01-08 13:27 ` Florian Weimer
0 siblings, 0 replies; 2+ messages in thread
From: Florian Weimer @ 2020-01-08 13:27 UTC (permalink / raw)
To: Chris Hall; +Cc: libc-help
* 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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-01-08 13:27 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-04 13:59 strerror_r -- GNU version Chris Hall
2020-01-08 13:27 ` Florian Weimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).