Re: Issue 8 POSIX changes coming

2020-03-24 Thread Robert Elz
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 change

Re: Issue 8 POSIX changes coming

2020-03-24 Thread Kamil Rytarowski
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

Re: Issue 8 POSIX changes coming

2020-03-24 Thread Joerg Sonnenberger
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 di

Re: Issue 8 POSIX changes coming

2020-03-24 Thread Robert Elz
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 discussion as recommented public interface for a long time. So | strerro

Re: Issue 8 POSIX changes coming

2020-03-24 Thread Joerg Sonnenberger
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

Re: Issue 8 POSIX changes coming

2020-03-24 Thread Robert Elz
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 ver

Re: Issue 8 POSIX changes coming

2020-03-23 Thread Robert Elz
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 eve

Re: Issue 8 POSIX changes coming

2020-03-23 Thread Joerg Sonnenberger
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 semi-d

Re: Issue 8 POSIX changes coming

2020-03-23 Thread Robert Elz
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() func

Re: Issue 8 POSIX changes coming

2020-03-23 Thread Joerg Sonnenberger
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

Issue 8 POSIX changes coming

2020-03-23 Thread Robert Elz
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 compl