Re: Issue 8 POSIX changes coming

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Tue, Mar 24, 2020 at 02:27:54PM +0700, Robert Elz wrote:
> Incidentally, is there a reason that strerror_lr is not exposed to
> userland, it has no prototype (not even one guarded by _NETBSD_SOURCE)
> anywhere in /usr/include/* and there's actually no alias for it
> (all that actually exists is the internal _strerror_lr name).
> 
> That violates your "We have _l versions of every function that depends
> on the (global) locale" doesn't it?   strerror_r depends upon the
> global locale, yet it appears that we don't actually have an _l version
> of that one.
> 
> Is this really intended only as an internal libc function (the one that
> actually does all the real work for all the strerror*() functions)
> or is it intended for users to be able to use that as well?
> 
> [If it matters, I vote for the latter interpretation.]
> 
> It seems like to expose it, all we need is a weak_alias() in strerror_r.c
> and a prototype in <string.h> (and doc...)

Yes, so far it has been intended only for internal use as strerror_l has
been in discussion as recommented public interface for a long time. So
strerror_l really is the locale-specific variant of strerror_r.

> Also, can someone explain strerror_ss() and strerror_r_ss() - which look
> to be implementations of the ancient (pre locale) strerror() functions, and
> as best I can see, exist solely for the purposes of jemalloc() ?
> They are exposed in libc, but have no prototypes - and I assume should
> not be used without a very good reason, and hence not be documented either.

They are for internal use only. They are meant for situations where you
can't allocate memory and don't really care that much about the one
situation were they can be racy (new/unknown error).

Joerg