Re: strncpy->strlcpy question

Ricardo Mestre wrote: > I made an inspection on userland tree and there quite a few > applications still using strncpy(3) instead of strlcpy(3). Some of > them may never need that safety since the boundaries are always fixed, > nevertheless since strlcpy is a drop-in replacement it doesn't hurt to

Re: utf8 input in el_gets(3)

Christian Heckendorf wrote: > * Michael McConville <mm...@mykolab.com> [24.12.2015. @16:19:03 -0500]: > > > Christian Heckendorf wrote: > > > A couple of somewhat recent changes in NetBSD's libedit permit > > > el_gets(3) to accept multiby

Re: utf8 input in el_gets(3)

Christian Heckendorf wrote: > A couple of somewhat recent changes in NetBSD's libedit permit > el_gets(3) to accept multibyte characters if the locale supports > it. > > A notable user of this function is sftp(1) which will allow users to > input multibyte characters, in filenames for example,

Re: [patch] basename(1) tweaks

frit...@alokat.org wrote: > Hi tech@, > > here are some basename(1) tweaks: > - remove (void) cast for puts(3) and fprintf(3) We typically leave these. I agree that they're usually pointless visual distractions in 2015 because there are a set of functions (mostly blocking IO functions to stdout

Re: [patch] basename(1) tweaks

Theo de Raadt wrote: > I don't know if I am alone in this -- I am getting a bit tired of > changes which are can be summarized as: "fighting someone else's > style". > > I do not really see the value in changes of this sort. Agreed. I ordered the includes, but the void casts should just stay.

allocation simplifications in yacc

1. realloc acts like malloc when ptr == NULL 2. no need to check for NULL before free ok? ? cscope.out Index: skeleton.c === RCS file: /cvs/src/usr.bin/yacc/skeleton.c,v retrieving revision 1.35 diff -u -p -r1.35 skeleton.c ---

Re: allocation simplifications in yacc

Michael McConville wrote: > 1. realloc acts like malloc when ptr == NULL > 2. no need to check for NULL before free > > ok? I found the same pair in libc. ok? Index: lib/libc/time/strftime.c === RCS file: /cvs/src/l

Re: OPENBSD performance // intel NIC interrupts // interrupt moderation

That dmesg got pretty severely mangled by Yahoo. Could you send it through an email client like Mutt or Thunderbird?

Re: Use off_t for lineno in csplit

Mark Kettenis wrote: > > Date: Sat, 12 Dec 2015 16:26:30 -0500 > > From: Michael McConville <mm...@mykolab.com> > > > > Mark Kettenis wrote: > > > It really is confusing to use off_t for something that's not a byte > > > offset. If integer

Re: Use off_t for lineno in csplit

Mark Kettenis wrote: > It really is confusing to use off_t for something that's not a byte > offset. If integer overflow really is an issue you care about, use > "long long". ok for the below diff to update my grep change? > Note that on many non-BSD systems off_t is still a 32-bit integer, at

Re: Pull tmpfs fix from NetBSD

Bob Beck wrote: > Stability before performance. Tmpfs does not have the former yet. ok mmcc@ for your PR_ZERO diff, as long as there's a comment added about the performance impact and the potential to back out in the future. I think it'd still be worthwhile to add the NULL assignment from

Re: Pull tmpfs fix from NetBSD

Stefan Sperling wrote: > On Fri, Dec 11, 2015 at 04:05:49PM -0500, Michael McConville wrote: > > Bob Beck wrote: > > > Stability before performance. Tmpfs does not have the former yet. > > > > ok mmcc@ for your PR_ZERO diff, as long as there's a comment added &g

Re: Pull tmpfs fix from NetBSD

Bob Beck wrote: > On Fri, Dec 11, 2015 at 01:09:30AM -0500, Michael McConville wrote: > > Here's the PR: > > > > https://gnats.netbsd.org/50381 > > > > And the commit: > > > > https://marc.info/?l=netbsd-source-changes=144694603617544=2 > >

[trivial] Specify SOCKS version in nc

Objections? Index: socks.c === RCS file: /cvs/src/usr.bin/nc/socks.c,v retrieving revision 1.22 diff -u -p -r1.22 socks.c --- socks.c 10 Dec 2015 16:49:28 - 1.22 +++ socks.c 10 Dec 2015 16:52:55 - @@ -278,7

Remove extraneous punctuation in unifdef.1

>From upstream, reduces diff: https://github.com/fanf2/unifdef/commit/cf9a7a6f161f3a83c587c485c362fea8d4c0e73e ok? Index: unifdef.1 === RCS file: /cvs/src/usr.bin/unifdef/unifdef.1,v retrieving revision 1.27 diff -u -p -r1.27

Remove allocation debugging junk from amd

ok? Index: amd/xutil.c === RCS file: /cvs/src/usr.sbin/amd/amd/xutil.c,v retrieving revision 1.17 diff -u -p -r1.17 xutil.c --- amd/xutil.c 26 Oct 2014 02:58:43 - 1.17 +++ amd/xutil.c 10 Dec 2015 20:04:43 - @@ -84,13

Pull tmpfs fix from NetBSD

Here's the PR: https://gnats.netbsd.org/50381 And the commit: https://marc.info/?l=netbsd-source-changes=144694603617544=2 We have very few local changes to tmpfs and we share the KASSERT(de->td_node == NULL), so I think this applies to us. Thoughts? ok? Index: sys/tmpfs/tmpfs_subr.c

Use off_t for lineno in csplit

I thought I'd look for other examples after the grep fix. ok? Index: csplit.c === RCS file: /cvs/src/usr.bin/csplit/csplit.c,v retrieving revision 1.8 diff -u -p -r1.8 csplit.c --- csplit.c11 Oct 2015 17:43:03 - 1.8

Re: OPENBSD performance // intel NIC interrupts // interrupt moderation

Jeff Drago wrote: > Hello - first post here , hopefully it is the right forum. > > I recently setup a bgp box on top of OPENBSD 5.5 Generic.MP, with 6 > INTEL EM nics.The problem is that when I get 700Mbits in one > interface, the CPU is peaking at 88% (interrupt). > > I read about interrupt

Re: Does grep need a version?

Bob Beck wrote: > Since I can't think of a sane reason to check this and care in any > script, yes, kill it. > ok beck@ Theo pointed out that there may be ports that check the version. I was considering that too. However, we haven't bumped from 0.9 since 2003. ggrep is now on 2.22, so I have hope

Re: [patch] dvmrpd: strings header cleanup

Serguey Parkhomovsky wrote: > Fixes implicit memcpy declarations by using string.h instead of > strings.h, and removes strings.h from files that don't need it. Also, > change bzero(3) to memset(3). Thanks for this. I just took care of the existing implicit declarations. Below is a diff for the

Re: [patch] dvmrpd: strings header cleanup

Serguey Parkhomovsky wrote: > Fixes implicit memcpy declarations by using string.h instead of > strings.h, and removes strings.h from files that don't need it. Also, > change bzero(3) to memset(3). This is all committed now. Thanks! > Index: ask_nbrs2.c >

Does grep need a version?

It's been 0.9 since the original import in 2003... Index: grep.1 === RCS file: /cvs/src/usr.bin/grep/grep.1,v retrieving revision 1.43 diff -u -p -r1.43 grep.1 --- grep.1 13 Jan 2015 04:45:34 - 1.43 +++ grep.1 8

Re: Move ancient ksh bug from README to man page

Jérémie Courrèges-Anglas wrote: > Jason McIntyre writes: > > > On Sun, Dec 06, 2015 at 04:03:16AM -0500, Ted Unangst wrote: > >> Jason McIntyre wrote: > >> > the trouble is i think there are some known bugs with ksh. i > >> > think it probably would be better to keep a note

Re: Move ancient ksh bug from README to man page

Ted Unangst wrote: > Jason McIntyre wrote: > > the trouble is i think there are some known bugs with ksh. i think > > it probably would be better to keep a note of them in a separate > > file, as is done now. i'm not really sure if we want to try and > > clutter the page with every bug we find. >

Re: Overflowable int -> size_t in grep

Michael McConville wrote: > This isn't a grave issue, but I came across it while exploring integer > overflow and think it's worth sharing. > > grep represents line numbers with an int, which predictably overflows > for inputs with >= 2^31 newlines. This is easy to demonstr

Overflowable int -> size_t in grep

This isn't a grave issue, but I came across it while exploring integer overflow and think it's worth sharing. grep represents line numbers with an int, which predictably overflows for inputs with >= 2^31 newlines. This is easy to demonstrate using the -n option and a debugging printf. The below

Re: Overflowable int -> size_t in grep

Otto Moerbeek wrote: > On Mon, Dec 07, 2015 at 01:36:22AM -0500, Michael McConville wrote: > > This isn't a grave issue, but I came across it while exploring integer > > overflow and think it's worth sharing. > > > > grep represents line numbers with an int,

Move ancient ksh bug from README to man page

Thoughts? ok? Index: README === RCS file: /cvs/src/bin/ksh/README,v retrieving revision 1.15 diff -u -p -r1.15 README --- README 5 Dec 2015 19:40:45 - 1.15 +++ README 6 Dec 2015 04:58:27 - @@ -15,8 +15,3 @@

Re: newfs: avoid oob read on command line argument

Tobias Stoeckmann wrote: > On Sat, Dec 05, 2015 at 06:26:35AM -0500, Ted Unangst wrote: > > may i suggest strlen(s) instead of strchr(s, 0)? > > There's actually one part in newfs' code that uses this. And in theory > it has the same issue, not checking if s (which is special, which might > be

Re: __progname in base

Tobias Stoeckmann wrote: > Opinions, thoughts? > > > [...] > > > > Index: sbin/newfs/newfs.c > > === > > RCS file: /cvs/src/sbin/newfs/newfs.c,v > > retrieving revision 1.100 > > diff -u -p -u -p -r1.100 newfs.c > > ---

Re: unifdef(1) - in-place editing without backups

Stuart Henderson wrote: > On 2015/12/02 00:04, Michael McConville wrote: > > unifdef's -M option is like sed's -i option, editing in-place and > > saving a backup with the supplied extension. > > There is an upstream for unifdef: http://dotat.at/prog/unifdef/ > Please ta

unifdef(1) - in-place editing without backups

unifdef's -M option is like sed's -i option, editing in-place and saving a backup with the supplied extension. Currently, if -M '' is passed: * the original file is copied to the backup filename (i.e. itself) * the temp file is copied to the original filename It therefore has the same

Re: Index underflow in lex(1)

Serguey Parkhomovsky wrote: > On Thu, Nov 26, 2015 at 01:03:22PM -0500, Michael McConville wrote: > > This nondeterministically underflows _sf_top_ix, causing a segfault: > > > > http://www.sccs.swarthmore.edu/users/16/mmcconv1/dump/crash.l > > > > Looks

Re: SOCKS strerrors for nc(1)

Theo de Raadt wrote: > Please KNF. > > case 90: > return "Succeeded"; > case 91: > > etc. New diff: Index: socks.c === RCS file: /cvs/src/usr.bin/nc/socks.c,v retrieving revision 1.21 diff -u -p -r1.21

SOCKS strerrors for nc(1)

When an nc SOCKS connection fails, you get an error message like this: > connection failed, SOCKS error 6 Obviously, this would be clearer with error strings. ok? Index: socks.c === RCS file: /cvs/src/usr.bin/nc/socks.c,v

A couple man page tweaks

1. A clearer wording of allocation failure 2. ksh has job control and is the default shell ok? Index: lib/libc/string/strdup.3 === RCS file: /cvs/src/lib/libc/string/strdup.3,v retrieving revision 1.21 diff -u -p -r1.21 strdup.3

Index underflow in lex(1)

This nondeterministically underflows _sf_top_ix, causing a segfault: http://www.sccs.swarthmore.edu/users/16/mmcconv1/dump/crash.l The cleanest way to trigger it is: for i in `jot 1000` do cat crash.l | ./lex -t > /dev/null done A backtrace is below. sf_pop() is the only code

lex(1) allocation cleanup

The second reallocarray is unnecessary, but it'll prevent the next forty auditors from being distracted by malloc(x * sizeof(y)). I'm happy to leave malloc if people prefer that. ok? Index: scanflags.c === RCS file:

Re: lex(1) allocation cleanup

Theo de Raadt wrote: > We need to make a decision if lex is upstream code or our own fork. > > If it is not our own fork -- then stay away from this. It is > pointless putting increasing delta into code which does not run in > risk environments. I thought we had already made that decision based

Re: lex(1) allocation cleanup

Theo de Raadt wrote: > > > If it is not our own fork -- then stay away from this. It is > > > pointless putting increasing delta into code which does not run in > > > risk environments. > > > > I thought we had already made that decision based on tedu's recent > > commits. Not sure though. > >

Re: Swap random with arcrandom on trek(6)

Ricardo Mestre wrote: > While checking if there was still a score file on trek(6) I found that > it was still using random(), and inspired by the code on NetBSD and > OpenBSD relevant manpages I came up with this diff. Let's bring > trek(6) to the 21st century, at least here :) Does it look good?

Re: Change PC's to PCs in www/i386.html

Larry Hynes wrote: > PC's is a possessive form, PCs a plural one: The plural of peecee is > peecees, not peecee's. Committed. Thanks. > Index: i386.html > === > RCS file: /cvs/www/i386.html,v > retrieving revision 1.735 > diff

int -> size_t in ksh

It seems apparent that they never go negative. All instances are used to manipulate strlen() values. ok? Index: c_ksh.c === RCS file: /cvs/src/bin/ksh/c_ksh.c,v retrieving revision 1.46 diff -u -p -r1.46 c_ksh.c --- c_ksh.c 21

Re: WAPBL implementation

I agree that this is very cool. It's probably also worth mentioning that there's a long discussion on NetBSD's tech-kernel@ right now about a WABPL-related panic. Not sure whether that's relevant to this diff.

Memory corruptions in bc(1)

I'm already cache-thrashing with all of my side projects, so if anyone's interested I'll leave this to them. A few days ago, I wanted to try American Fuzzy Lop (afl), and bc(1) seemed like a good first target: it pretty much just goes from stdin to stdout, so there's no code reorganization

Re: calloc -> malloc in get_data() and get_string()

Ted Unangst wrote: > Joerg Jung wrote: > > > Michael McConville wrote: > > > Relayd, httpd, and ntpd define the functions get_data() and > > > get_string(). Both call calloc and then immediately memcpy. > > > Calloc's zeroing isn't optimized out. These fun

Re: ypserv h

Ted Unangst wrote: > memory.h is spelled string.h now. ok? Index: etherent.c === RCS file: /cvs/src/lib/libpcap/etherent.c,v retrieving revision 1.7 diff -u -p -r1.7 etherent.c --- etherent.c 27 Jan 2004 06:58:03 - 1.7

Re: Reducing compilation warnings in imsg.c on FreeSBD

Craig Rodrigues wrote: > Recently, I imported imsg.c from OpenBSD to the > FreeBSD base system's libopenbsd: > > https://svnweb.freebsd.org/changeset/base/290375 > > When compiling on FreeBSD, we get a compiler warning with clang: > > cc -O2 -pipe -I/opt2/branches/head2/lib/libopenbsd

[trivial] int -> size_t in pax(1)

ok? Index: pax.h === RCS file: /cvs/src/bin/pax/pax.h,v retrieving revision 1.27 diff -u -p -r1.27 pax.h --- pax.h 19 Mar 2015 05:14:24 - 1.27 +++ pax.h 16 Nov 2015 18:23:24 - @@ -79,7 +79,7 @@ typedef

Signed indexing in bc(1)

I may be missing something obvious here, but it seems that the below indices should be unsigned. str_table has UCHAR_MAX elements, so it expects to be indexed by chars > 127. I'm currently digging through a bunch of segfaults found by American Fuzzy Lop (afl). I don't think I've come across this

Re: apmd(8) messages

Jan Stary wrote: > When we set perf policy to high, we say "high". > So when we set to low, say "low", not "manual". > (Both manual high and manual low are manual.) > > And it's not "client reply", it's a reply to the client, right? ok mmcc@ > Index: apmd.c >

Re: pledge for tetris

Ted Unangst wrote: > Theo Buehler wrote: > > drop the score file support > > No way! this is critical functionality. :) Seconded. :P

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Alexandre Ratchov wrote: > On Thu, Nov 12, 2015 at 02:52:01PM +0800, Michael W. Bombardieri wrote: > > > > ok for removing xfree from aucat? > > > > > > yes, ok ratchov; if later this causes me merges i'll find another > > > solution. Feel free to do the same in usr.bin/sndiod, as it's > > >

Re: Replace xfree with free on csh(1)

Ricardo Mestre wrote: > It seems I was still with mangling problems, does it look good now? You're still wrapping a couple lines in the second-to-last hunk, but I fixed them manually. ok mmcc@ > Index: alloc.c > === > RCS file:

Re: Replace xfree with free on csh(1)

Ricardo Mestre wrote: > Hi, > > On csh(1), since Free() just calls free() and xfree() is a #define to > Free() then free() can be called directly instead of xfree() and the > #define can be removed, is this approach correct? Seems like this patch is mangled, unless it's something on my machine.

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Michael W. Bombardieri wrote: > > > ok for removing xfree from aucat? > > > > yes, ok ratchov; if later this causes me merges i'll find another > > solution. Feel free to do the same in usr.bin/sndiod, as it's > > almost the same. > > Same thing for sndiod... ok mmcc@ > Index: abuf.c >

More less(1)

That helper function I just tweaked has a total of one usage. Maybe just inline it? Index: opttbl.c === RCS file: /cvs/src/usr.bin/less/opttbl.c,v retrieving revision 1.16 diff -u -p -r1.16 opttbl.c --- opttbl.c12 Nov 2015

less(1) ctype fixes

is_optchar() could also take an int in order to be more compatible with the ctype functions. isupper() || islower() is equivalent to isalpha() in the C locale, but not necessarily in others (see the isalpha(3) manpage). We could use stdbool to make is_optchar() a one-liner, but I'll resist the

Re: [patch] dc: array_free usage

Michael W. Bombardieri wrote: > Hi tech@, > > In dc(1) the function array_free() knows how to skip a null pointer so > calling code doesn't need to avoid passing null. > Also, minor style (braces) clean-up. ok mmcc@ It may also be a good idea to change the allocation names in the form bmalloc

Re: restore typo

Manuel Giraud wrote: > Hi, > > Here is a typo in the verbose mode of restore: ok mmcc@ > Index: tape.c > === > RCS file: /cvs/src/sbin/restore/tape.c,v > retrieving revision 1.46 > diff -u -p -r1.46 tape.c > --- tape.c25 Aug

Re: remove superfluous case '?': from /sbin utils

Benjamin Baier wrote: > Hello tech@ > > I cleaned up and split up my former diff[0] for removing superfluous > case '?': /*FALLTHROUGH*/ > default: > usage(); > > Also removes one unnecessary break; > > This is for /sbin, more to come if there are any takers? >

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Alexandre Ratchov wrote: > On Sun, Nov 08, 2015 at 09:56:23AM +0800, Michael W. Bombardieri wrote: > > On Thu, Nov 05, 2015 at 03:50:29PM +0100, Tobias Stoeckmann wrote: > > > On Thu, Nov 05, 2015 at 09:50:48AM +, Nicholas Marriott wrote: > > > > I don't know why cvs and rcs xmalloc.c has

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Maybe we should pick this off in smaller chunks so that we don't get immobilized by a few scattered issues. ok for removing xfree from aucat? Index: abuf.c === RCS file: /cvs/src/usr.bin/aucat/abuf.c,v retrieving revision 1.26 diff

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Michael McConville wrote: > Maybe we should pick this off in smaller chunks so that we don't get > immobilized by a few scattered issues. > > ok for removing xfree from aucat? I just realized that this one was already submitted separately. Tobias, could you split your latest diff i

less(1) cleanup

Here, I: 1) remove a useless comment 2) remove a needless void* cast 3) remove a bunch of NULL-checks for free() 4) simplify a little associated logic Call me a one trick pony. ok? Index: cmdbuf.c === RCS file:

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Nicholas Marriott wrote: > Looks good, ok nicm Reviewing now, generally looks good. A few things: I don't understand the motive for all the err() -> errx() and fatal() -> fatalx() changes. If I came across these, I probably would have suggested the reverse. err(1, "xstrdup") is a lot cleaner

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Michael W. Bombardieri wrote: > On Thu, Nov 05, 2015 at 03:50:29PM +0100, Tobias Stoeckmann wrote: > > On Thu, Nov 05, 2015 at 09:50:48AM +, Nicholas Marriott wrote: > > > I don't know why cvs and rcs xmalloc.c has ended up so different. > > > > It's not just about cvs and rcs: > > > >

Re: save less

Ted Unangst wrote: > less has a peculiar estrdup function. unlike ecalloc etc., it only > prints an error but doesn't quit. But the callers don't seem to check > for null. And in many places they call a function called save() > instead. > > It is clearer to make estrdup() quit and use it

Re: patch: fix top

Marc Espie wrote: > On Thu, Nov 05, 2015 at 11:52:32AM +0100, Theo Buehler wrote: > > On Thu, Nov 05, 2015 at 11:33:56AM +0100, Marc Espie wrote: > > > On Thu, Nov 05, 2015 at 10:54:32AM +0100, Theo Buehler wrote: > > > > On Thu, Nov 05, 2015 at 10:42:54AM +0100, Marc Espie wrote: > > > > > -

Re: patch: fix top

Michael McConville wrote: > > It's not documented so it doesn't exist for me. :P > > > > (hint hint) > > Seconded. I thought thought that this was referring to the undocumented top option. Disregard. :)

err(3) trivia

Apparently the programmer didn't know that you could pass it NULL. However, including the function name seems more informative. ok? Index: usr.sbin/netgroup_mkdb/util.c === RCS file: /cvs/src/usr.sbin/netgroup_mkdb/util.c,v

Another uvm(9) tweak

It's probably best to say that UVM_MAPFLAG() returns a uvm_flag_t. It's almost exclusively used for uvm_map()'s flag arg, which has that type. Of course, it's an arithmetic macro, so it doesn't actually have a return type. ok? Index: share/man/man9/uvm.9

Re: Another uvm(9) tweak

Ted Unangst wrote: > Michael McConville wrote: > > It's probably best to say that UVM_MAPFLAG() returns a uvm_flag_t. It's > > almost exclusively used for uvm_map()'s flag arg, which has that type. > > Of course, it's an arithmetic macro, so it doesn't actually have a > >

Re: [patch] cvs: retire xfree()

Michael W. Bombardieri wrote: > Hi tech@, > > Function xfree() was previously removed from rcs, so drop it from > opencvs too... > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/rcs/xmalloc.c?f=h#rev1.9 Good catch, thanks. My eyes glazed over a little while reviewing this, but

Unsigned char cast for ctype func in uniq(1)

ok? Index: usr.bin/uniq/uniq.c === RCS file: /cvs/src/usr.bin/uniq/uniq.c,v retrieving revision 1.22 diff -u -p -r1.22 uniq.c --- usr.bin/uniq/uniq.c 9 Oct 2015 01:37:09 - 1.22 +++ usr.bin/uniq/uniq.c 2 Nov 2015 17:17:13

cvs(1) simplification

Don't bother mallocing a statically-sized 1,024-byte chunk of mem, for simplicity and speed. ok? Index: usr.bin/cvs/server.c === RCS file: /cvs/src/usr.bin/cvs/server.c,v retrieving revision 1.102 diff -u -p -r1.102 server.c ---

Re: LibreSSL MIPS64 build with GCC5

Ruslan Babayev wrote: > This fixes the portable LibreSSL build on Linux with GCC5 for MIPS64. Is __GNUC_PREREQ__ from /usr/include/sys/cdefs.h in other OSs? If not, you could probably just add it to the LibreSSL portability headers. It's probably the easiest and most readable solution if these

Unsigned char cast for ctype in whois(1)

ok? Index: usr.bin/whois/whois.c === RCS file: /cvs/src/usr.bin/whois/whois.c,v retrieving revision 1.50 diff -u -p -r1.50 whois.c --- usr.bin/whois/whois.c 9 Oct 2015 01:37:09 - 1.50 +++ usr.bin/whois/whois.c

Re: Drop register keyword from less(1)

Todd C. Miller wrote: > On Mon, 02 Nov 2015 09:16:07 +, Nicholas Marriott wrote: > > I looked briefly at this and it wouldn't be that hard. However, > > while it would be fantastic to clean up all the crap from less, it > > isn't clear if Garrett D'Amore is going to be keeping his fork up to >

Re: cvs(1) simplification

on. So, maybe we should only change it in performance-relevant areas where we're very confident in the safety of the program logic. > On Mon, Nov 02, 2015 at 12:31:14PM -0500, Michael McConville wrote: > > Don't bother mallocing a statically-sized 1,024-byte chunk of mem, for > >

Re: Upgrading flex?

Serguey Parkhomovsky wrote: > Is there any interest in having a newer version of flex in base? I > recently tried compiling some software with OpenBSD's flex, but had to > tweak some code in order to get it to compile with 2.5.4. Of course, I > could always install the flex in ports to get a newer

Tweaks to malloc(3) manpage

1. I don't see much reason to mention calloc() as an alternative to reallocarray() when it's the worse option. 2. Use size > 0 when testing overflow. ok? Index: lib/libc/stdlib/malloc.3 === RCS file:

Re: Another use of areallocarray() in ksh

Michael McConville wrote: > Mike Burns wrote: > > On 2015-11-01 10.44.45 -0500, Michael McConville wrote: > > > Index: history.c > > > === > > > RCS file: /cvs/src/bin/ksh/history.c,v > > &

Another use of areallocarray() in ksh

ok? Index: history.c === RCS file: /cvs/src/bin/ksh/history.c,v retrieving revision 1.52 diff -u -p -r1.52 history.c --- history.c 1 Nov 2015 15:38:53 - 1.52 +++ history.c 1 Nov 2015 15:44:02 - @@ -507,7 +507,7 @@

Re: Another use of areallocarray() in ksh

Mike Burns wrote: > On 2015-11-01 10.44.45 -0500, Michael McConville wrote: > > Index: history.c > > === > > RCS file: /cvs/src/bin/ksh/history.c,v > > retrieving revision 1.52 > > diff -u -p -r1.52 hi

Drop register keyword from less(1)

Every one of these is in a var declaration, so a megadiff is probably the easiest way to do it. ok? Index: brac.c === RCS file: /cvs/src/usr.bin/less/brac.c,v retrieving revision 1.6 diff -u -p -r1.6 brac.c --- brac.c 25 Apr

Merge bugfix from NetBSD's mountd(8)

The two most recent diffs here: http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/mountd/mountd.c?only_with_tag=MAIN Here's the referenced PR: https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48282 Essentially, we daemonize after rather than before registering the

Re: Merge bugfix from NetBSD's mountd(8)

Michael McConville wrote: > Diff below. Is anyone running an NFS server on -current willing to > test? Disregard, this needs more initial testing (by me) first. It's hanging when registering the service. > Index:

Re: ntpd doesn't work with -sv - syscall 5

Gregory Edigarov wrote: > ntpd_flags=-sv > > Oct 29 11:19:32 lbld12 /bsd: ntpd(15132): syscall 5 > Oct 29 11:19:32 lbld12 ntpd[697]: ntp_dispatch_imsg in ntp engine: pipe > closed > Oct 29 11:19:32 lbld12 ntpd[10730]: dispatch_imsg in main: pipe closed > > Without flags everithing works. We at

Re: calloc -> malloc in get_data() and get_string()

Sebastian Benoit wrote: > Michael McConville(mm...@mykolab.com) on 2015.10.28 12:05:24 -0400: > > Relayd, httpd, and ntpd define the functions get_data() and > > get_string(). Both call calloc and then immediately memcpy. Calloc's > > zeroing isn't optimized out. These

Re: __predict_false for pledge

Ted Unangst wrote: > Michael McConville wrote: > > Ted Unangst wrote: > > > Michael McConville wrote: > > > > We have a pretty strong guarantee that it can only happen once > > > > per process... > > > > > > I don't think this really m

Finally use ksh's areallocarray()

With help from Theo Buehler. ok? Index: c_sh.c === RCS file: /cvs/src/bin/ksh/c_sh.c,v retrieving revision 1.53 diff -u -p -r1.53 c_sh.c --- c_sh.c 21 Oct 2015 15:20:37 - 1.53 +++ c_sh.c 29 Oct 2015 18:15:25 -

Wrong return type in uvm(9)

This one confused me for a few minutes. See sys/uvm/uvm_user.c for the function definition. ok? Index: share/man/man9/uvm.9 === RCS file: /cvs/src/share/man/man9/uvm.9,v retrieving revision 1.60 diff -u -p -r1.60 uvm.9 ---

calloc -> malloc in get_data() and get_string()

Relayd, httpd, and ntpd define the functions get_data() and get_string(). Both call calloc and then immediately memcpy. Calloc's zeroing isn't optimized out. These functions are called in network data paths in at least a couple places, so all this extra writing could have a meaningful performance

Re: Further cleanup of unused macros

Ilya Kaliman wrote: > Index: bin/ksh/emacs.c > === > RCS file: /cvs/src/bin/ksh/emacs.c,v > retrieving revision 1.60 > diff -u -p -r1.60 emacs.c > --- bin/ksh/emacs.c 19 Oct 2015 14:42:16 - 1.60 > +++ bin/ksh/emacs.c 27

[trivial] (type *)0 -> NULL

While I'm in here: Index: sys/lib/libsa/net.c === RCS file: /cvs/src/sys/lib/libsa/net.c,v retrieving revision 1.19 diff -u -p -r1.19 net.c --- sys/lib/libsa/net.c 26 Oct 2015 02:33:07 - 1.19 +++ sys/lib/libsa/net.c 26 Oct

Re: __predict_false for pledge

Ted Unangst wrote: > Michael McConville wrote: > > We have a pretty strong guarantee that it can only happen once per > > process... > > I don't think this really matters. What does it do to the assmembly, > and how does that make things faster? It lets the compiler kn

Re: __predict_false for pledge

Philip Guenther wrote: > On Mon, Oct 26, 2015 at 8:46 AM, Michael McConville <mm...@mykolab.com> wrote: > > We have a pretty strong guarantee that it can only happen once per > > process... > ... > > --- sys/sys/syscall_mi.h9 Oct 2015 01:17:18 - 1.1

PF_KEY socket data sensitivity

There are a few daemons in base that make a point of zeroing all data read from PF_KEY sockets. However, Benjamin Baier and I have looked into it a litle (RFC 2367 et al.) and it seems that this may only be metadata. To those with PF_KEY experience: is it worth zeroing?

<    1   2   3   >