Re: dc(1): minor cleanup

On Sun, Nov 26, 2017 at 07:25:46PM +, kshe wrote: > Hi, > > The diff below encompasses three unrelated minor changes. > > 1. Merge the not_equal(), not_less() and not_greater() functions into > their caller; these functions cannot be called from the jump table, so > it is confusing to

Re: dc.1: document non-portability of `e'

On Mon, Nov 27, 2017 at 10:34:50AM +, Jason McIntyre wrote: > On Sun, Nov 26, 2017 at 07:18:33PM +, kshe wrote: > > Hi, > > > > The manual page for dc(1) is very careful about signalling which > > commands are non-portable extensions, with the exception of the `e' > > command, which is a

Re: freezero(3) for stdio's internal buffers

On Mon, Nov 27, 2017 at 05:48:14AM +, kshe wrote: > On Mon, 27 Nov 2017 00:42:01 +, Theo de Raadt wrote: > > This needs worst-case performance measurements. > > The only instances where performance could be a problem are in > vfprintf.c and vfwprintf.c, where the calls happen inside a

Re: dc(1): smaller jump table

Thanks for the diffs. I'll try to process them this week starting with the more simple ones, -Otto On Sun, Nov 26, 2017 at 07:23:24PM +, kshe wrote: > Hi, > > The jump table used in dc/bcode.c is technically off by one, which leads > to the following harmless inconsistency: > >

Re: fuse: vfs create does not map 1:1 to fuse create

On Sat, Nov 18, 2017 at 02:22:43AM +, Helg Bredow wrote: > On Fri, 10 Nov 2017 09:09:32 +0100 > Martin Pieuchot wrote: > > > On 09/11/17(Thu) 01:20, Helg Bredow wrote: > > > > On 08/11/17(Wed) 14:12, Helg Bredow wrote: > > > > > There is a bug when creating a file in

Re: yacc: malloc+copy -> strndup()

On Fri, Nov 03, 2017 at 04:22:43PM +0800, Michael W. Bombardieri wrote: > On Fri, Nov 03, 2017 at 04:03:44PM +0800, Michael W. Bombardieri wrote: > > Hello, > > > > In yacc the dup_line() function malloc()'ed a buffer and copied > > a line into it. The copied line includes \n. > >

Re: bc(1) examples

On Sun, Oct 08, 2017 at 11:10:06PM +0200, Jan Stary wrote: > On Oct 08 11:31:16, o...@drijf.net wrote: > > On Fri, Oct 06, 2017 at 02:12:01PM +0200, Jan Stary wrote: > > > > > Isn't "4 * a(1)" a more natural incarnation of pi than "2 * a(2^1)"? > > > > The point of this example is to (also)

Re: bc(1) examples

On Fri, Oct 06, 2017 at 02:12:01PM +0200, Jan Stary wrote: > Isn't "4 * a(1)" a more natural incarnation of pi than "2 * a(2^1)"? The point of this example is to (also) show that a() works on very large numbers. -Otto > > Jan > > > Index: bc.1 >

Re: sin() implementation

On Fri, Sep 29, 2017 at 11:16:24AM +0200, Alexandre Ratchov wrote: > On Wed, Sep 27, 2017 at 03:09:48PM +0200, Joerg Sonnenberger wrote: > > On Wed, Sep 27, 2017 at 08:40:26AM +0200, Alexandre Ratchov wrote: > > > Even on modern amd64s integer arithmetics and bitwise operations are > > > faster

Re: sin() implementation

On Tue, Sep 26, 2017 at 01:27:52PM +0200, Jan Stary wrote: > I picked sin() as an example while trying to walk though the implementation > of (pieces of) libm. If someone has the time for it, I have some questions. > > I understand the implementation originaly stems from Sun's libm of 1993. >

Re: sin() implementation

On Tue, Sep 26, 2017 at 06:21:16PM +0200, Jan Stary wrote: > These (diff below) seem to be obvious typos in k_sin.c, > but only in comments. The comment that says > > if x < 2^-27 (hx<0x3e40), return x with inexact if x!=0 > > also puzzles me a bit: what the code does is > >

Re: malloc.c: better double free check

On Sun, Sep 24, 2017 at 09:02:58PM -0400, Daniel Micay wrote: > > In the end all double frees still will be caught by the actual free > > code, just with a delay. The delayed free buffer double free check is > > just a way of catching it as soon as possible to make debugging > > easier. That's

Re: malloc.c: better double free check

On Sat, Sep 23, 2017 at 05:19:58PM -0400, Daniel Micay wrote: > On Sat, 2017-09-23 at 09:32 +0200, Otto Moerbeek wrote: > > On Fri, Sep 22, 2017 at 04:35:39PM -0400, Daniel Micay wrote: > > > > > A linear search works well for the current small quarantine (16) but >

Re: malloc.c: better double free check

On Sat, Sep 23, 2017 at 05:28:57AM -0400, Ted Unangst wrote: > Otto Moerbeek wrote: > > Hi, > > > > Malloc maintains a list if 16 slots of chunks to be freed. On free a > > chunk is put in a random slot and the existing chunk in that slot is > > actually freed

Re: malloc.c: better double free check

On Fri, Sep 22, 2017 at 04:35:39PM -0400, Daniel Micay wrote: > A linear search works well for the current small quarantine (16) but won't > work > well if you ever want to have a larger / configurable quarantine size. It > would > also be nice to make this fast enough to enable by default. >

malloc.c: better double free check

Hi, Malloc maintains a list if 16 slots of chunks to be freed. On free a chunk is put in a random slot and the existing chunk in that slot is actually freed. Currently, the code only checks the slot selected for a double free. This diff adds code to check all slots. It also removes the option to

Re: [patch] In malloc.conf(5), explain what options S includes/enables.

On Sun, Sep 17, 2017 at 08:52:49AM -0600, Theo de Raadt wrote: > > The mentioning of the S option in malloc.conf(5) won't actually tell the > > user what flags it enables. Rephrased this and list the options. > > In our original discussion, that was done intentionally. The flags > in use can

malloc:check double free before canary

Hi, A double free of a chunk corrupts the canary, but I prefer to see a double free error reported, -Otto Index: malloc.c === RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v retrieving revision 1.228 diff -u -p -r1.228

Re: more pax warning fixes

On Thu, Sep 07, 2017 at 02:30:20PM -0600, Todd C. Miller wrote: > Why not just use strtol() then? The check against MINXHDRSZ > will catch any negative values. > > - todd Indeed, better diff, -Otto Index: tar.c === RCS

more pax warning fixes

Hi, this fixes the following clang warnings: /usr/src/bin/pax/tar.c:1257:11: warning: comparison of integers of different signs: 'unsigned long' and 'long' [-Wsign-compare] if (len > end - p) { ~~~ ^ ~~~ /usr/src/bin/pax/tar.c:1262:12: warning: comparison

Re: tcpdump fork+exec?

On Thu, Sep 07, 2017 at 12:27:18AM -0400, Bryan Steele wrote: > Hi, > > This turned out easier then pflogd thanks to the existing privsep design > work done by deraadt@ and canacar@ many years ago. While tcpdump isn't a Small correction for the record: done by otto@ and cancacar@ while being

warnings in pax

Hi, clang complains about a quite some signed compares in pax. This fixes a few of them, all of the form if (var < sizeof(...)) where var is an int. Here a conversion of the int value to unsigned takes place, due to the conversion rules. This causes negative values of var not to be

Re: enum unsigned or not?

On Thu, Aug 31, 2017 at 05:10:27PM +0200, Boudewijn Dijkstra wrote: > Op Thu, 31 Aug 2017 14:08:07 +0200 schreef Otto Moerbeek <o...@drijf.net>: > > /usr/src/usr.sbin/sasyncd/carp.c:157:12: warning: comparison of > > unsigned enum expression < 0 is always false

enum unsigned or not?

Hi, /usr/src/usr.sbin/sasyncd/carp.c:157:12: warning: comparison of unsigned enum expression < 0 is always false [-Wtautological-compare] if (state < 0 || state > FAIL) ~ ^ ~ /usr/src/usr.sbin/sasyncd/carp.c:166:20: warning: comparison of unsigned enum expression < 0 is

Re: Unbreak DEBUG for nfsd(8)

On Wed, Aug 30, 2017 at 08:01:36PM +0100, Ricardo Mestre wrote: > On 19:30 Wed 30 Aug , Otto Moerbeek wrote: > > On Wed, Aug 30, 2017 at 05:54:16PM +0100, Ricardo Mestre wrote: > > > > > Hi, > > > > > > Unbreak DEBUG for nfsd(8), this one was caug

Re: Unbreak DEBUG for nfsd(8)

On Wed, Aug 30, 2017 at 05:54:16PM +0100, Ricardo Mestre wrote: > Hi, > > Unbreak DEBUG for nfsd(8), this one was caught with cppcheck. > > It has been broken for about 7 years ago when a couple of errx calls, which > had > string format arguments, were replaced by syslog calls. Can you

iked const ** warning

Hi, this one is a bit tricky (cee http://c-faq.com/ansi/constmismatch.html), it fixes the warning: /usr/src/sbin/iked/crypto.c:854:44: warning: cast from 'uint8_t **' (aka 'unsigned char **') to 'const uint8_t **' (aka 'const unsigned char **') must have all intermediate pointers

Re: reiser4fs in openbsd

On Fri, Aug 25, 2017 at 02:31:10PM +0300, Андрей Болконский wrote: > hello! If I will achieve change of license for reiser4 FS on BSD and ported > it to the openbsd, you accept it? > And what about Journaling in openbsd? We do not make promises about accepting code, especially if it does not

Re: freezero(NULL, 0)

On Thu, Aug 24, 2017 at 11:34:52AM +1000, Damien Miller wrote: > Hi, > > memset(NULL, 0, 0) is (strictly speaking) undefined behaviour, but > there's no reason that freezero(3) needs to follow suit. > > This mentions that freezero(NULL, 0) is valid in the manpage, so that > anyone who copies

Re: sed(1): missing NUL in pattern space

On Sat, Jul 01, 2017 at 01:20:19PM +, kshe wrote: > On Tue, 27 Jun 2017 09:29:10 +0000, Otto Moerbeek wrote: > > > > at last a followup, for the original problem. > > > > This diff incorporates your later comment. It does not cause the newly > > a

Re: sed(1): missing NUL in pattern space

On Thu, Jun 15, 2017 at 09:01:15AM +0200, Otto Moerbeek wrote: at last a followup, for the original problem. This diff incorporates your later comment. It does not cause the newly added regress test to fail, though. So that poses the question if this is what you meant. -Otto Index

Re: sed(1): missing NUL in pattern space

On Tue, Jun 13, 2017 at 10:08:11AM +, kshe wrote: > On Sat, 10 Jun 2017 10:25:27 +0000, Otto Moerbeek wrote: > > Thanks for the analysis and diff, I hope to get a chanche to think > > about this soon. At least I'll make sure this diff is not forgotten, > > -Otto >

Re: sed(1): missing NUL in pattern space

On Fri, Jun 09, 2017 at 07:58:48AM +, kshe wrote: > Hi, > > There is an ongoing confusion in sed's source about the concept of EOL: > the code contradicts itself as to whether it should be determined by a > trailing NUL or by looking up the `len' field of the SPACE structure. > > At least

Re: improving qsort worst case behavior

On Sat, May 20, 2017 at 10:20:42AM +0200, Otto Moerbeek wrote: > On Fri, May 19, 2017 at 09:04:30AM -0600, Todd C. Miller wrote: > > > On Thu, 18 May 2017 09:58:14 -0600, "Todd C. Miller" wrote: > > > > > I believe the best approach is to switch qsor

Re: improving qsort worst case behavior

On Fri, May 19, 2017 at 09:04:30AM -0600, Todd C. Miller wrote: > On Thu, 18 May 2017 09:58:14 -0600, "Todd C. Miller" wrote: > > > I believe the best approach is to switch qsort.c to "introsort". > > The changes are minimal and the elimination of the O(n^2) worst > > case is compelling. > >

Re: Emulated TLS for clang

On Sun, May 07, 2017 at 05:37:47PM +0200, Mark Kettenis wrote: > So this enables the code. It makes -femulated-tls the default, > otherwise it will generated TLS relocations that we can't handle yet. > It is possible to specify -fno-emulated-tls if you really want to > generate those. > > A

Re: malloc.3: make arguments consistent in example code

On Wed, Apr 05, 2017 at 11:21:00PM -0700, Christopher Hettrick wrote: > Hi tech@ > > The arguments to malloc() in the EXAMPLE section are not consistent. > Make a couple other consistency fixes as well. Committed, thanks, -Otto > > Index: malloc.3 >

Re: sync root.mail

On Thu, Mar 30, 2017 at 06:44:37AM +, Miod Vallat wrote: > >> > Ambiguous: choose package for emacs--no_x11 > >> > a 0: > >> > 1: emacs-21.4p37-no_x11 > >> > 2: emacs-25.1p3-no_x11 > >> > Your choice: > >> > >> Time to choose another package? > > > > I think in this

Re: sync root.mail

On Wed, Mar 29, 2017 at 10:52:23PM +0200, Antoine Jacoutot wrote: > On Wed, Mar 29, 2017 at 09:40:32PM +0200, Christian Weisgerber wrote: > > Antoine Jacoutot: > > > > > Why not just: > > > > > > # pkg_add -v rsync chromium emacs--no_x11 > > > > > > So we don't have to change it each release?

Re: dsdt: redundant assignment

On Sun, Mar 26, 2017 at 06:31:41PM +1100, Jonathan Gray wrote: > On Sun, Mar 26, 2017 at 09:14:26AM +0200, Anton Lindqvist wrote: > > Hi, > > An assignment introduced in r1.219 looks redundant. > > child is assigned every iteration of the loop this diff looks wrong to me. It's being assigned in

Re: www/61.html reallocarray(1) typo

On Fri, Mar 10, 2017 at 04:26:24PM +0100, Hiltjo Posthuma wrote: > Hey, > > I think a small typo slipped in the 6.1 notes. Patch below: Nope, the actual new functions is called recallocarray... -Otto > > diff --git a/61.html b/61.html > index 4b5dadbd4..18208b588 100644 > ---

a new libc function: recallocarray(3)

le: stdlib/recallocarray.c diff -N stdlib/recallocarray.c --- /dev/null 1 Jan 1970 00:00:00 - +++ stdlib/recallocarray.c 2 Mar 2017 14:34:17 - @@ -0,0 +1,81 @@ +/* $OpenBSD$ */ +/* + * Copyright (c) 2008, 2017 Otto Moerbeek <o...@drijf.net> + * + * Permission to

Re: dc: do {} while() as an arg in bn_check()

On Sun, Feb 26, 2017 at 11:49:13AM +0100, Daniel Cegiełka wrote: > 2017-02-26 8:27 GMT+01:00 Otto Moerbeek <o...@drijf.net>: > > On Sat, Feb 25, 2017 at 11:28:43PM +0100, Daniel Cegiełka wrote: > > > > > > > Bleh, they could have changed the impleme

Re: dc: do {} while() as an arg in bn_check()

On Sat, Feb 25, 2017 at 11:28:43PM +0100, Daniel Cegiełka wrote: > 1) bcode.c and bn_check() call > > bn_check(BN_zero(f)); > > https://github.com/openbsd/src/blob/master/usr.bin/dc/bcode.c#L389 > https://github.com/openbsd/src/blob/master/usr.bin/dc/bcode.c#L807 >

Re: [PATCH] bc(1) should write error messages to standard error

On Tue, Feb 21, 2017 at 07:19:13AM +0100, Otto Moerbeek wrote: > On Tue, Feb 21, 2017 at 07:00:34AM +0100, Otto Moerbeek wrote: > > > On Tue, Feb 21, 2017 at 04:08:57AM +0100, Martijn Dekker wrote: > > > > > Upon encountering a parsing error, bc(1) passes an err

Re: [PATCH] bc(1) should write error messages to standard error

On Tue, Feb 21, 2017 at 07:00:34AM +0100, Otto Moerbeek wrote: > On Tue, Feb 21, 2017 at 04:08:57AM +0100, Martijn Dekker wrote: > > > Upon encountering a parsing error, bc(1) passes an error message on to > > dc(1), which writes the error message to standard output along w

Re: [PATCH] bc(1) should write error messages to standard error

On Tue, Feb 21, 2017 at 04:08:57AM +0100, Martijn Dekker wrote: > Upon encountering a parsing error, bc(1) passes an error message on to > dc(1), which writes the error message to standard output along with the > normal output. > > That is a bug. Error messages should go to standard error

Re: realloc(3) and MALLOC_MOVE

On Tue, Jan 24, 2017 at 10:07:23AM +0100, Otto Moerbeek wrote: > Hi, > > malloc(3) has the nice feature to move (subject to alignment > constraints) allocations that are between the max chunk size (half a > page) and a page size towards the end of the allocated page, to catc

realloc(3) and MALLOC_MOVE

Hi, malloc(3) has the nice feature to move (subject to alignment constraints) allocations that are between the max chunk size (half a page) and a page size towards the end of the allocated page, to catch more buffer overflows. Due to the allocation being higher up within a page, buffer overflows

Re: ksh(1): preserve xtrace option

On Fri, Jan 13, 2017 at 09:51:51AM +0100, Otto Moerbeek wrote: > On Fri, Jan 13, 2017 at 09:46:54AM +0100, Anton Lindqvist wrote: > > > Consider the following script which calculates the sum of the first N > > integers recursively: > > > > $ cat >sum.sh < >

Re: ksh(1): preserve xtrace option

On Fri, Jan 13, 2017 at 09:46:54AM +0100, Anton Lindqvist wrote: > Consider the following script which calculates the sum of the first N > integers recursively: > > $ cat >sum.sh < sum() { > [ $1 -eq 0 ] && echo $2 || sum $(($1 - 1)) $(($2 + $1)) > } > > sum 5 > ! > > Executing the script

Re: improve realloc(3)

On Mon, Jan 09, 2017 at 07:49:24PM +0100, Otto Moerbeek wrote: > Hi, > > this diff implements some improvements to realloc and some cleanup of > the MALLOC_MOVE code. > > 1. When shrinking a chunk allocation, compare the size of the current > allocation to the size

improve realloc(3)

Hi, this diff implements some improvements to realloc and some cleanup of the MALLOC_MOVE code. 1. When shrinking a chunk allocation, compare the size of the current allocation to the size of the new allocation (instead of the requested size). Current code does a malloc-free-copy dance in too

Re: yacc: loop -> memcpy

On Thu, Jan 05, 2017 at 05:13:24PM +0800, Michael W. Bombardieri wrote: > Hi, > > Two loops in yacc/lalr.c can be converted into memcpy(). > I quickly tested this on i386 and amd64 against rcs/date.y > and the output matched y.tab.c of unpatched yacc. Some remarks: 1. use of magic nunber 2.

Re: List Ericsson N5321gw as supported umb(4) device

On Wed, Nov 23, 2016 at 08:56:53PM +0100, Ingo Feinerer wrote: > Hi, > > the "Lenovo N5321gw" is working for me with umb(4) > (https://marc.info/?l=openbsd-misc=147992993614369=2). So mention it > as a supported device in umb.4? > > (Lenovo seems to call it Ericsson N5321gw on its support

Re: Possible typos in find(1) man page

On Thu, Nov 24, 2016 at 04:42:37PM +0100, Senthil Kumar M wrote: > Hello Tech, > > In the find(1) man page, for the option `-f': > > -f path > Specifies a file hierarchy for find to traverse. File > hierarchies may be specified without the -f option if they are >

Re: removed goal with cdrom-based release

On Sun, Nov 13, 2016 at 09:30:26PM +0300, Sergey Bronnikov wrote: > OK? Nope, the goal still is to have a release every six months (at least for me). Just the way it is distributed changed. -Otto > > diff --git a/goals.html b/goals.html > index c94d4cb..ef0dbcc 100644 > ---

Re: [PATCH] umb(4) fixes for ifconfig

On Thu, Nov 10, 2016 at 02:12:55PM +0100, Gerhard Roth wrote: > On Thu, 10 Nov 2016 13:56:00 +0100 Otto Moerbeek <o...@drijf.net> wrote: > > On Wed, Nov 09, 2016 at 08:51:04AM -0800, Bryan Vyhmeister wrote: > > > > > This patch accomplishes two things for umb

Re: [PATCH] umb(4) fixes for ifconfig

On Wed, Nov 09, 2016 at 08:51:04AM -0800, Bryan Vyhmeister wrote: > This patch accomplishes two things for umb(4) connections. One, some SIM > cards have a plus at the beginning of the phone number while others do > not. In my case, an AT Wireless SIM card in the US has the plus where > a

Re: malloc options cleanuip

On Sun, Oct 30, 2016 at 07:37:27AM +0100, Otto Moerbeek wrote: > Hi, > > remove some old option letters and also make P non-settable. It has > been the default for ages, and I see no valid reason to be able to > disable it. > > OK? No feedback,... I will commit this diff

H option for malloc

Hi, Pages in the malloc cache are either reused quickly or unmapped quickly. In both cases it does not make sense to set hints on them. So remove that option, which is just a remainder of old times when mallco used to hold on to pages. OK? -Otto Index: lib/libc/stdlib/malloc.c

port of latest libc malloc changes to ld.so

Hi, survived a make build on amd64 and armv7 here. Note that canaries are always enabled in ld.so's malloc. ok? -Otto Index: malloc.c === RCS file: /cvs/src/libexec/ld.so/malloc.c,v retrieving revision 1.14 diff -u -p

Re: malloc canaries for > page sized objects

On Thu, Oct 20, 2016 at 01:50:41PM +0200, Otto Moerbeek wrote: > On Thu, Oct 20, 2016 at 11:28:37AM +0200, Otto Moerbeek wrote: > > > On Thu, Oct 20, 2016 at 11:21:26AM +0200, Otto Moerbeek wrote: > > > > > On Thu, Oct 20, 2016 at 11:17:25AM +0200, Otto Moerbeek w

Re: malloc canaries for > page sized objects

On Thu, Oct 20, 2016 at 11:28:37AM +0200, Otto Moerbeek wrote: > On Thu, Oct 20, 2016 at 11:21:26AM +0200, Otto Moerbeek wrote: > > > On Thu, Oct 20, 2016 at 11:17:25AM +0200, Otto Moerbeek wrote: > > > > > On Thu, Oct 20, 2016 at 04:42:13AM -0400, Ted Unangst

Re: malloc canaries for > page sized objects

On Thu, Oct 20, 2016 at 11:21:26AM +0200, Otto Moerbeek wrote: > On Thu, Oct 20, 2016 at 11:17:25AM +0200, Otto Moerbeek wrote: > > > On Thu, Oct 20, 2016 at 04:42:13AM -0400, Ted Unangst wrote: > > > > > Otto Moerbeek wrote: > > > > That is certainly n

Re: malloc canaries for > page sized objects

On Thu, Oct 20, 2016 at 11:17:25AM +0200, Otto Moerbeek wrote: > On Thu, Oct 20, 2016 at 04:42:13AM -0400, Ted Unangst wrote: > > > Otto Moerbeek wrote: > > > That is certainly not correct: snprintf and friends return the length as > > > it would have been if

Re: malloc canaries for > page sized objects

On Thu, Oct 20, 2016 at 04:42:13AM -0400, Ted Unangst wrote: > Otto Moerbeek wrote: > > That is certainly not correct: snprintf and friends return the length as > > it would have been if an infinite buffer was passed in. > > So the strlen should stay. I'll make a

Re: malloc canaries for > page sized objects

On Tue, Oct 18, 2016 at 11:12:39AM +0200, Theo Buehler wrote: > > That is certainly not correct: snprintf and friends return the length as > > it would have been if an infinite buffer was passed in. > > So the strlen should stay. > New diff, though the snprintf return value check might be

Re: malloc canaries for > page sized objects

On Tue, Oct 18, 2016 at 03:23:32AM +0200, Theo Buehler wrote: > On Sun, Oct 16, 2016 at 01:14:35PM +0200, Otto Moerbeek wrote: > > Hi, > > > > this diff is somewhat big since I decided to rewrite wrterror() to be > > able to get better error messages. >

Re: diff3: use boolean OR, not bitwise

On Sun, Oct 16, 2016 at 08:44:34AM -0600, Todd C. Miller wrote: > On Sun, 16 Oct 2016 16:06:39 +0200, Otto Moerbeek wrote: > > > On Sun, Oct 16, 2016 at 07:07:36AM -0600, Todd C. Miller wrote: > > > > > It is effectively the same in this case but using the boolean

malloc canaries for > page sized objects

Hi, this diff is somewhat big since I decided to rewrite wrterror() to be able to get better error messages. Please review and test this with malloc option C (and other flags). An example run: a.out(85360) in free(): chunk canary corrupted 0x13c68f696000 0x18a92@0x18a88 This means I overwrote

malloc junk bytes

Hi, 0xdb is better dan 0xd0, since it is unaligned in more cases (think about the bytes being used as a pointer. ok? -Otto Index: lib/libc/stdlib/malloc.c === RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v retrieving

Re: systat(1) hostname

On Thu, Oct 13, 2016 at 08:20:52AM +0200, Otto Moerbeek wrote: > On Thu, Oct 13, 2016 at 08:01:22AM +0200, Otto Moerbeek wrote: > > > On Thu, Oct 13, 2016 at 12:15:34AM -0400, Ted Unangst wrote: > > > > > Theo de Raadt wrote: > > > > > On Wed, Oct 1

Re: systat(1) hostname

On Thu, Oct 13, 2016 at 12:15:34AM -0400, Ted Unangst wrote: > Theo de Raadt wrote: > > > On Wed, Oct 12, 2016 at 03:20:00PM +0200, Otto Moerbeek wrote: > > > > simple diff to show the hostname on the second line. OK? > > > > > > OK bluhm@ > > >

systat(1) hostname

Hi, simple diff to show the hostname on the second line. OK? BTW, batch mode doesn't function here as expected. Need to look into that, -Otto Index: main.c === RCS file: /cvs/src/usr.bin/systat/main.c,v retrieving

Re: Fix off by 1 in sed

On Mon, Oct 10, 2016 at 09:53:55PM +0200, Martijn van Duren wrote: > Hello tech@, > > As reported and fixed by pfg@freebsd. > Fixes the following case: > % echo z | gsed -n -e 's/^a*/b/2p' > # empty -- correct > % echo z | sed -n -e 's/^a*/b/2p' > z # incorrect > > Fix in FreeBSD r302973 > >

Re: optimization for chunk canaries

On Sat, Oct 08, 2016 at 06:40:00PM +0200, Otto Moerbeek wrote: > Hi, > > avoid recomping the offset by storing it in the chunk info, ok? anyone? > > -Otto > > Index: stdlib/malloc.c > === >

Re: bring two libc malloc features to ld.so's own malloc

On Sat, Oct 08, 2016 at 05:30:11PM -0700, Philip Guenther wrote: > On Sat, 8 Oct 2016, Otto Moerbeek wrote: > > Canaries and chunk validation on delayed free, > > > > OK? > > There are still significant differences between the libc malloc and the > ld.so malloc af

bring two libc malloc features to ld.so's own malloc

Hi, Canaries and chunk validation on delayed free, OK? -Otto Index: malloc.c === RCS file: /cvs/src/libexec/ld.so/malloc.c,v retrieving revision 1.12 diff -u -p -r1.12 malloc.c --- malloc.c18 Sep 2016 13:54:58 -

optimization for chunk canaries

Hi, avoid recomping the offset by storing it in the chunk info, ok? -Otto Index: stdlib/malloc.c === RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v retrieving revision 1.199 diff -u -p -r1.199 malloc.c --- stdlib/malloc.c

Re: Fix boundary issue in chacha code

On Fri, Oct 07, 2016 at 03:06:28PM -0500, Brent Cook wrote: > > > On Oct 7, 2016, at 2:52 PM, Otto Moerbeek <o...@drijf.net> wrote: > > > > On Fri, Oct 07, 2016 at 02:33:13PM -0500, Brent Cook wrote: > > > >> > >>> On Oct 7, 2016

Re: better implementation of malloc option C: canaries

On Mon, Oct 03, 2016 at 07:57:13AM +0200, Otto Moerbeek wrote: > Hi, > > I have been working on a diff to do canaries in a better way. > > Canaries (enabled by the C malloc option) are values stored after the > requested size that are checked for being overwritten o

Re: disklabel template: percentage of disk optional?

On Thu, Oct 06, 2016 at 09:15:50AM +0200, Theo Buehler wrote: > On Thu, Oct 06, 2016 at 08:57:44AM +0200, Otto Moerbeek wrote: > > On Tue, Oct 04, 2016 at 01:26:06PM +0200, Otto Moerbeek wrote: > > > > > On Tue, Oct 04, 2016 at 04:00:50AM -0700, Claus Assmann wrote: >

Re: disklabel template: percentage of disk optional?

On Tue, Oct 04, 2016 at 01:26:06PM +0200, Otto Moerbeek wrote: > On Tue, Oct 04, 2016 at 04:00:50AM -0700, Claus Assmann wrote: > > > On Tue, Oct 04, 2016, Dmitrij D. Czarkoff wrote: > > > > [please do not Cc me] > > > > > I shouldn't have started on send

Re: disklabel template: percentage of disk optional?

On Tue, Oct 04, 2016 at 04:00:50AM -0700, Claus Assmann wrote: > On Tue, Oct 04, 2016, Dmitrij D. Czarkoff wrote: > > [please do not Cc me] > > > I shouldn't have started on sending patches at 3AM. This one should do > > what I intended it to do. Sorry for noise. > > > + else if (t

better implementation of malloc option C: canaries

Hi, I have been working on a diff to do canaries in a better way. Canaries (enabled by the C malloc option) are values stored after the requested size that are checked for being overwritten on calling free(3). At the moment we only do this for chunks (sub-page sized allocations). To be able to

Re: login.conf processing by /etc/rc

On Thu, Sep 29, 2016 at 03:33:48PM +0300, Evgeny Grin wrote: > > > On 29.09.2016 13:57, Otto Moerbeek wrote: > > On Thu, Sep 29, 2016 at 11:45:21AM +0300, Evgeny Grin wrote: > >> May be it also worth to mention in /etc/login.conf comments, that if > >>

Re: login.conf processing by /etc/rc

On Thu, Sep 29, 2016 at 11:45:21AM +0300, Evgeny Grin wrote: > > > On 29.09.2016 8:08, Otto Moerbeek wrote: > > On Thu, Sep 29, 2016 at 12:10:47AM +0300, Evgeny Grin wrote: > > > >> Hi! > >> > >> I configured freshly installed OpenBSD

Re: login.conf processing by /etc/rc

On Thu, Sep 29, 2016 at 12:10:47AM +0300, Evgeny Grin wrote: > Hi! > > I configured freshly installed OpenBSD 6.0-release with > > kern.maxfiles=131072 > > in /etc/sysctl.conf > and > > :openfiles-max=40960:openfiles-cur=40960: > > for daemon in /etc/login.conf > > And at each boot I see

Re: random malloc junk

On Wed, Sep 14, 2016 at 05:41:55AM +0200, Theo Buehler wrote: > On Tue, Sep 13, 2016 at 01:29:17PM +0200, Otto Moerbeek wrote: > > As often, real life came in between. Did anybody do measurements? I > > really would like to to see hard data. > > It seems that the price

Re: random malloc junk

On Fri, Sep 16, 2016 at 09:30:15PM +0200, Otto Moerbeek wrote: > On Thu, Sep 15, 2016 at 10:08:26AM -0400, Ted Unangst wrote: > > > Otto Moerbeek wrote: > > > On Wed, Sep 14, 2016 at 12:53:05PM -0400, Ted Unangst wrote: > > > > > > > Daniel Micay wrote

Re: random malloc junk

On Thu, Sep 15, 2016 at 10:08:26AM -0400, Ted Unangst wrote: > Otto Moerbeek wrote: > > On Wed, Sep 14, 2016 at 12:53:05PM -0400, Ted Unangst wrote: > > > > > Daniel Micay wrote: > > > > > > > > The current OpenBSD code only wipes up to MALLOC_

Re: random malloc junk

On Thu, Sep 08, 2016 at 08:15:42AM +0200, Otto Moerbeek wrote: > On Wed, Sep 07, 2016 at 06:29:07PM -0400, Ted Unangst wrote: > > > Instead of always using a fixed byte pattern, I think malloc should use a > > random pattern. Now, this sometimes means it's harder to identify

Re: random malloc junk

On Thu, Sep 08, 2016 at 06:42:33PM -0400, Daniel Micay wrote: > On Wed, 2016-09-07 at 18:29 -0400, Ted Unangst wrote: > > Instead of always using a fixed byte pattern, I think malloc should > > use a > > random pattern. Now, this sometimes means it's harder to identify > > exactly > > what's used

Re: random malloc junk

On Thu, Sep 08, 2016 at 07:47:58PM -0400, Daniel Micay wrote: > A nice security property of 0xdf filling is that a use-after-free of a > pointer is guaranteed to fault in a typical environment since it ends up > pointing outside userspace (I assume that's the case on OpenBSD). A heap > spray

Re: Default softraid crypto PBKDF2 rounds

On Tue, Sep 06, 2016 at 01:56:32PM +0100, Filippo Valsorda wrote: > Hello, > > I recently had the occasion to dive into the softraid crypto code [1] > and was quite pleased with the cleanliness of it all. However, I found > surprising the default value of 8k PBKDF2 rounds. > > I know it is easy

Re: mount(8): strlen + malloc + snprintf == asprintf

On Mon, Sep 05, 2016 at 10:47:06AM +0300, Ali H. Fardan wrote: > On 2016-09-05 10:44, David Gwynne wrote: > > > On 5 Sep 2016, at 17:39, Ali H. Fardan wrote: > > > > > > and why is he telling me this? I just said if the destination is a > > > pointer to char, how would a

Re: mount(8): strlen + malloc + snprintf == asprintf

On Mon, Sep 05, 2016 at 08:05:40AM +0300, Ali H. Fardan wrote: > On 2016-09-05 08:01, David Gwynne wrote: > > > On 5 Sep 2016, at 12:13, Ali H. Fardan wrote: > > > > > > You can't specify a buffer size in asprintf() therefore, it is not > > > secure, > > > you can see that

Re: multi-pool malloc wip diff

On Tue, Aug 23, 2016 at 09:57:03AM +0200, Otto Moerbeek wrote: > On Mon, Aug 22, 2016 at 08:59:44PM -0400, Ted Unangst wrote: > > > Otto Moerbeek wrote: > > > > > > After a forkl of a threaded program __isthreaded is reset, but > > > existing allocations a

Re: better return type for usqrt() in factor(6)

On Thu, Sep 01, 2016 at 06:36:15AM +0100, Theo Buehler wrote: > In factor(6), there is the line > > 216 stop = usqrt(val) + 1; > > where the u_int64_t stop is the upper bound for the sieve of > Eratosthenes (I cautiously added 1 to be sure to be on the safe side). > Unfortunately, the

<    1   2   3   4   5   6   7   8   9   >