Date: Mon, 23 Mar 2020 10:48:04 +0000
From: Austin Group Bug Tracker <nore...@msnkbrown.net>
Message-ID: <cea1a68030964b152ae2321d06a9c...@austingroupbugs.net>
| The following issue has a resolution that has been APPLIED.
| ======================================================================
| https://austingroupbugs.net/view.php?id=655
While looking into what this actually meant (the bug report, and its
resolution, were from before my time here) I noticed a minor issue that
might be able to be fixed at the same time ? Or do we really need a
new bug report?
That is, strerror_l() takes a locale_t paramater, but the prototypes
don't indicate that <locale.h> needs to be included to define that.
It is kind of obvious, but "kind of obvious" isn't really good enough.
While here, I'd also say that I disagree with the statement in the
original bug report:
The strerror_l function is mandatory beginning with issue 7,
[not that part, but]
provides a much easier-to-use interface to the same functionality,
[that part]
The only functionality of strerror_r that strerror_l duplicates is
thread safety. strerror_r also allows an application to (easily)
translate several errnums to messages, before deciding which of them to
use, or perhaps before using all of them simultaneously. Obviously an
app can strcpy() (or one of its variants) the message from strerror_l()
into a private buffer (the one that would be used for strerror_r) but
that is not "a much easier-to-use interface".
If the resolution of this issue had been as suggested, to:
Mark strerror_r obsolescent ...
then I would have objected, but as it stops short of that, and simply
points out (without naming names) that glibc screwed things, and so
using strerror_r() can cause issues if not done carefully. That is fine.
For the same reason, I'm not sure that I agree with what is currently in
the Rationale, that a strerror_l tyoe equivalent to strerror_r is not required.
NetBSD has one (internally: the strerror{,_l,_r} functions use it to do the
work), and it (strerror_lr) might be exposed to userland sometime soon
(might be.)
kre
