Updating src tree:
P src/lib/librumpuser/rumpuser_sp.c
P src/share/man/man9/cprng.9
P src/share/mk/bsd.README
P src/sys/arch/arm/sociox/if_ave.c
P src/sys/arch/arm/sociox/if_scx.c
P src/sys/arch/arm/sociox/sni_gpio.c
P src/sys/arch/arm/sunxi/files.sunxi
P src/sys/arch/evbarm/conf/MMNET_GENERIC
P
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
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
Hi,
I accidentally noticed that padlock engine is not included on AMD64
port (neither as module or built-in). Is there any reason it excluded
from it? The build currently fails because inline asm code is using
pushl, popl instructions in the code in via_padlock_cbc method, but
replacing them with
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
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 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
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
Hi Andreas.
On Mon, Mar 23, 2020 at 04:11:17PM +0200, Andreas Gustafsson wrote:
> In September and November, I reported some measurements of the amount
> of system time it takes to build a NetBSD-8/amd64 release on different
> versions of -current/amd64. I have now repeated the measurements
