Date:Tue, 24 Mar 2020 15:48:07 +0100
From:Joerg Sonnenberger
Message-ID: <20200324144807.ga63...@bec.de>
| strerror is already thread-safe.
Ours is, I know, but assuming that isn't portable, it isn't promised,
and some implementations are not. (My man page
On 24.03.2020 15:27, Robert Elz wrote:
> Are there any objections to making strerror_lr() user visible?
There are no users.
Our strerror() is already thread-safe.
signature.asc
Description: OpenPGP digital signature
On Tue, Mar 24, 2020 at 09:27:54PM +0700, Robert Elz wrote:
> Date:Tue, 24 Mar 2020 14:13:30 +0100
> From:Joerg Sonnenberger
> Message-ID: <20200324131330.ga60...@bec.de>
>
> | Yes, so far it has been intended only for internal use as strerror_l has
> | been in
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
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
Date:Mon, 23 Mar 2020 19:16:36 +0100
From:Joerg Sonnenberger
Message-ID: <20200323181636.ga123...@bec.de>
| We have _l versions of every function that depends on the (global)
| locale.
That's good to know - I don't often venture near the libc internals.
It is
On Tue, Mar 24, 2020 at 12:58:15AM +0700, Robert Elz wrote:
> Date:Mon, 23 Mar 2020 18:09:50 +0100
> From:Joerg Sonnenberger
> Message-ID: <20200323170950.ga120...@bec.de>
>
> | On Mon, Mar 23, 2020 at 11:50:37PM +0700, Robert Elz wrote:
> | > strerror_r is
Date:Mon, 23 Mar 2020 18:09:50 +0100
From:Joerg Sonnenberger
Message-ID: <20200323170950.ga120...@bec.de>
| On Mon, Mar 23, 2020 at 11:50:37PM +0700, Robert Elz wrote:
| > strerror_r is semi-deprecated, Issue 7 (current POSIX) already has a
| > strerror_l()
On Mon, Mar 23, 2020 at 11:50:37PM +0700, Robert Elz wrote:
> strerror_r is semi-deprecated, Issue 7 (current POSIX) already has a
> strerror_l() function we do not seem to support.
We do have it.
Joerg
This contains a list of some of the non-trivial (such as formatting fixes,
corrections to the rationale, ...) that are going to be in POSIX 8 (and no,
no idea yet when that will appear).
When I know a change is irrelevant to NetBSD, I will omit mention of it
(that is, where I know we already
10 matches
Mail list logo
