Re: malloc.conf.5: minor correction

On Sat, Dec 30, 2017 at 06:16:44AM +, kshe wrote: > Hi, > > The `F' option no longer disables delayed freeing. > > Also, I think documenting implementation details like the exact value > of the junk bytes is not very useful. When you are debugging, it is good to see if a buffer is filled

Re: sh.1: backslash within double quotes

On Sat, Dec 30, 2017 at 06:01:56AM +, kshe wrote: > Hi, > > Within double quotes, backslashes also escape newlines. This is > correctly documented in ksh.1, but not in sh.1. > fixed, thanks. jmc > Index: sh.1 > === > RCS

Re: jot(1): one-byte overflow in error path

On Sat, Dec 30, 2017 at 05:55:57AM +, kshe wrote: > Hi, > > If the format string ends in an invalid specifier like `%l', p will > already point to the trailing NUL upon entering the switch, wherein the > instruction > > *++p = '\0'; > > will write another NUL after it, but there is no

malloc.conf.5: minor correction

Hi, The `F' option no longer disables delayed freeing. Also, I think documenting implementation details like the exact value of the junk bytes is not very useful. Index: malloc.conf.5 === RCS file:

Re: malloc cleanup and small optimization (step 2)

Hi, Looking at this diff and the previous one, I found some more possible cleanups for malloc.c (the patch below is to be applied after both of them, even if the second one has not been committed yet): 1. In malloc_bytes(), use ffs(3) instead of manual loops, which on many architectures boils

sh.1: backslash within double quotes

Hi, Within double quotes, backslashes also escape newlines. This is correctly documented in ksh.1, but not in sh.1. Index: sh.1 === RCS file: /cvs/src/bin/ksh/sh.1,v retrieving revision 1.145 diff -u -p -r1.145 sh.1 --- sh.1

jot(1): one-byte overflow in error path

Hi, If the format string ends in an invalid specifier like `%l', p will already point to the trailing NUL upon entering the switch, wherein the instruction *++p = '\0'; will write another NUL after it, but there is no guarantee that the buffer extends beyond that first NUL; thus, in the

Re: pf state key linking mbuf assert

Hello, On Fri, Dec 29, 2017 at 11:04:07PM +0100, Alexander Bluhm wrote: > On Thu, Dec 28, 2017 at 12:46:45AM +0100, Alexandr Nedvedicky wrote: > > I like your change. You have my OK with small change here: > > I have commitet my diff with a small addition. I fixed a memory > leak that I had

Re: pf state key linking mbuf assert

On Thu, Dec 28, 2017 at 12:46:45AM +0100, Alexandr Nedvedicky wrote: > I like your change. You have my OK with small change here: I have commitet my diff with a small addition. I fixed a memory leak that I had introduced before. > > -pf_pkt_state_key_ref(struct mbuf *m) > >

paste(1): default to stdin if no files given

Currently paste(1) silently does nothing if it's given no file arguments: % printf 'hello\nworld\n'|paste % I often do things like 'ps -p $(pgrep sh | paste -sd,)' and forget the "-" argument. Some other systems (gnu coreutils, illumos, perhaps more) default to reading from stdin if no

Re: armv7 / A33 clock and pinctrl bindings

On Fri, Dec 29, 2017 at 02:04:32PM +0100, Mark Kettenis wrote: > > > Date: Thu, 28 Dec 2017 10:07:12 +0800 > > From: Kevin Lo > > > > On Wed, Dec 27, 2017 at 10:48:16AM +0100, Mark Kettenis wrote: > > > > > > > Date: Wed, 27 Dec 2017 09:37:12 +0800 > > > > From: Kevin Lo

Re: armv7 / A33 clock and pinctrl bindings

> Date: Thu, 28 Dec 2017 10:07:12 +0800 > From: Kevin Lo > > On Wed, Dec 27, 2017 at 10:48:16AM +0100, Mark Kettenis wrote: > > > > > Date: Wed, 27 Dec 2017 09:37:12 +0800 > > > From: Kevin Lo > > > > > > On Tue, Dec 26, 2017 at 06:20:59PM +0100, Mark

Re: armv7 unaligned access in libcrypto

> Date: Fri, 29 Dec 2017 21:21:04 +1100 > From: Jonathan Gray > > On Fri, Dec 29, 2017 at 10:47:06AM +0100, Mark Kettenis wrote: > > The Aarch32 assembly code in libcrypto assumes that armv7 supports > > unaligned access. It does, but only if you don't enable the bit that > >

Re: armv7 unaligned access in libcrypto

On Fri, Dec 29, 2017 at 10:47:06AM +0100, Mark Kettenis wrote: > The Aarch32 assembly code in libcrypto assumes that armv7 supports > unaligned access. It does, but only if you don't enable the bit that > makes it trap on unaligned access. And we enable that bit on OpenBSD. > So doing a SHA256

armv7 unaligned access in libcrypto

The Aarch32 assembly code in libcrypto assumes that armv7 supports unaligned access. It does, but only if you don't enable the bit that makes it trap on unaligned access. And we enable that bit on OpenBSD. So doing a SHA256 of an unaligned buffer (something ftp(1) ends up doing) you SIGBUS.