Re: Minor improvement to socket(2) man page

Philip Guenther wrote: > On Wed, Sep 21, 2016 at 6:23 PM, Michael McConville <mm...@mykolab.com> wrote: > > The current version is somewhat awkward and forgets to mention that > > errno is set. I adapted the paragraph found in most other system call > > man pages.

Minor improvement to socket(2) man page

The current version is somewhat awkward and forgets to mention that errno is set. I adapted the paragraph found in most other system call man pages. Thanks for your time, Mike Index: lib/libc/sys/socket.2 === RCS file:

PF error message tweak

The below error message sequence isn't as clear as it could be: > mike:/home/mike$ doas pfctl -f /etc/pf. > pfctl: /etc/pf.: No such file or directory > pfctl: cannot open the main config file!: No such file or directory > pfctl: Syntax error in config file: pf rules not loaded There are

Re: malloc: add full delayed chunk double-free detection

Daniel Micay wrote: > This uses a hash table to maintain a set of delayed allocations, > allowing full and efficient double-free detection. The current code > can only catch it when the two pointers being swapped are equal, so > double-frees that could be caught are missed. A naive loop over every

Re: midiplay: Fix out-of-bounds memory access

Vadim Zhukov wrote: > 2016-04-30 7:38 GMT+03:00 Jonathan Gray : > > On Wed, Apr 27, 2016 at 07:49:50PM -0700, Geoff Hill wrote: > >> Fix possible reads past the end of the buffer. > >> > >> Found by random fuzz testing (zzuf). Without the fix the fuzzer crashes > >> in several

Re: bufcache KNF

Ted Unangst wrote: > Martin Pieuchot wrote: > > ok? > > > > -int chillbufs(struct > > -bufcache *cache, struct bufqueue *queue, int64_t *queuepages); > > +int chillbufs(struct bufcache *, struct bufqueue *, int64_t *); > > fwiw i like names in prototypes, so i know what's going on. i know >

Re: Pledge error handling

Héctor Luis Gimbatti wrote: > I noticed there are (at least 2) diferent ways to handle a pledge > error (eg: /usr/src/usr.bin/): > > If (pledge(args, NULL) == -1) > . err(1, "pledge"); (wc; w; ..) > . perror("pledge"); exit(EXIT_CODE); (vi; openssl; ...) > > I am not familiar with the case of

Re: spamd - DNS whitelist

Bob Beck wrote: > No. DNS based whitelisting does not belong in there. because it is > slow and DOS'able > > spamd is designed to be high speed low drag. If you want to do a DNS > based whitelist, write a little co-thing that spits one into a file or > into your nospamd table that then spamd

Re: Possible kernel function with stack frame > 2048 bytes

Michael McConville wrote: > Clang 3.7 gives this warning when building the kernel: > > > ../../../../dev/audio.c:1852:1: warning: stack frame size of 2504 bytes in > > function 'wskbd_initvol' [-Wframe-larger-than=] > > wskbd_initvol(struct audio_softc *sc, struct wskbd_

Possible kernel function with stack frame > 2048 bytes

Clang 3.7 gives this warning when building the kernel: > ../../../../dev/audio.c:1852:1: warning: stack frame size of 2504 bytes in > function 'wskbd_initvol' [-Wframe-larger-than=] > wskbd_initvol(struct audio_softc *sc, struct wskbd_vol *vol, char *cn, char > *dn) > ^ -Wframe-larger-than was

[mm...@mykolab.com: Merge memleak fix from BoringSSL]

Does this look good? - Forwarded message from Michael McConville <mm...@mykolab.com> - Date: Sun, 20 Mar 2016 23:15:48 -0400 From: Michael McConville <mm...@mykolab.com> To: libre...@openbsd.org Subject: Merge memleak fix from BoringSSL Looks like it applies t

Re: Fix overflow check in sys/kern/kern_time.c

Mark Kettenis wrote: > > I'm not sure whether avoiding incrementing here is an ideal move, but > > this diff definitely works toward a local optimum. Namely, that error > > check is technically meaningless because signed overflow is undefined. > > Within the kernel, signed overflow actually is

Fix overflow check in sys/kern/kern_time.c

I'm not sure whether avoiding incrementing here is an ideal move, but this diff definitely works toward a local optimum. Namely, that error check is technically meaningless because signed overflow is undefined. ok? Or would people prefer a solution that's robust to changing *curpps's type?

Re: Scheduler hack for multi-threaded processes

Douglas Ray wrote: > On 21/03/16 11:29 AM, Mark Kettenis wrote: > >>From: Amit Kulkarni > >>Date: Sun, 20 Mar 2016 17:57:49 -0500 > ... > >>+1. Previously, when I did a cvs update with original scheduler code, doing > >>the ports update the machine always froze solid while

Re: kern_sched.c: unused functions

Michal Mazurek wrote: > On 17:19:39, 2.03.16, Martin Natano wrote: > > On Wed, Mar 02, 2016 at 05:07:21PM +0100, Michal Mazurek wrote: > > > kern_sched.c: > > > - remove unused functions > > > - mark static functions as static > > > > Functions shouldn't be static in the kernel. "In userland, >

Re: New scheduler for OpenBSD

Bob Beck wrote: > this is cool .. but > > I would be interested in someone comparing server workloads, as > opposed to interactive GUI response, using this. > > I wouldn't be surprised that inspiriation from BFS would produce > better interactive response, my bigger concern would be does this >

Re: stty header cleanup

One correction: Edgar Pettijohn wrote: > Index: cchar.c > === > RCS file: /cvs/src/bin/stty/cchar.c,v > retrieving revision 1.11 > diff -u -p -u -r1.11 cchar.c > --- cchar.c27 Oct 2009 23:59:22 -1.11 > +++ cchar.c16

Re: stty header cleanup

ok mmcc@ Edgar Pettijohn wrote: > Index: cchar.c > === > RCS file: /cvs/src/bin/stty/cchar.c,v > retrieving revision 1.11 > diff -u -p -u -r1.11 cchar.c > --- cchar.c27 Oct 2009 23:59:22 -1.11 > +++ cchar.c16 Mar 2016

Re: ed header cleanup

ok mmcc@ Edgar Pettijohn wrote: > Index: buf.c > === > RCS file: /cvs/src/bin/ed/buf.c,v > retrieving revision 1.22 > diff -u -p -u -r1.22 buf.c > --- buf.c9 Oct 2015 19:47:02 -1.22 > +++ buf.c16 Mar 2016 23:23:53

Re: New scheduler for OpenBSD

Edd Barrett wrote: > On Sat, Mar 19, 2016 at 09:06:26AM +0100, Alexandre Ratchov wrote: > > The browsers problems seem caused by the way pthreads behave; > > browsers appear to spin. With the proposed scheduler they spin > > less. But the real question is why they spin at all? > > Inspired by

Guard a macro arg in less(1)

ok? Index: ch.c === RCS file: /cvs/src/usr.bin/less/ch.c,v retrieving revision 1.16 diff -u -p -r1.16 ch.c --- ch.c27 Dec 2015 17:51:19 - 1.16 +++ ch.c15 Mar 2016 17:18:56 - @@ -103,8 +103,8 @@ struct

Re: spamd - blacklists

Stuart Henderson wrote: > On 2016/03/15 12:55, Craig Skinner wrote: > > There are a few more paid rsync lists here: > > http://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists > > Ah that is a useful page. Maybe we could list it, e.g. > > Index: spamd.conf >

Re: Optimizing chmod(1)

Adam Thompson wrote: > > On 16-03-13 11:11 PM, Michael McConville wrote: > >It seems that chown(1) will write to a file even if it already has the > >desired ownership. The below patch causes it to skip the write when > >there would be no change. The best I co

Re: spamd - blacklists

Craig Skinner wrote: > Hi Hans, > > On 2016-03-14 Mon 11:49 AM |, hans wrote: > > On Mar 13 18:56:00, mm...@mykolab.com wrote: > > > hans wrote: > > > > The link to "the place to search for blacklists" is dead. > > > > > > Might be better to replace it than to remove it. > > > > Sure. Any

Optimizing chmod(1)

It seems that chown(1) will write to a file even if it already has the desired ownership. The below patch causes it to skip the write when there would be no change. The best I could tell, the fts_read(3) and fchownat(3) logic agree on whether to follow symlinks in all cases, so there's no need to

Re: spamd - blacklists

hans wrote: > The link to "the place to search for blacklists" is dead. Might be better to replace it than to remove it. > Index: spamd.conf > === > RCS file: /cvs/src/etc/mail/spamd.conf,v > retrieving revision 1.4 > diff -u -p

Remove lint(1) reference from gcc-local(1)

As jmc@ asked when I shared this with him, is there a remaining use of our custom gcc -CC flag now that lint(1) is gone? It seems like it could be useful for general macro debugging, but I'm not sure. Even if not, removing it might be more effort than it's worth. I'm interested to hear what

Re: remove 'returns no value' from man pages

Marc Espie wrote: > On Fri, Mar 11, 2016 at 05:18:52PM -0800, Michael McConville wrote: > > This is specified only irregularly, and people who don't know what a > > void return type means are beyond help anyway. > > > > This also adds a sentence specifying that X50

remove 'returns no value' from man pages

This is specified only irregularly, and people who don't know what a void return type means are beyond help anyway. This also adds a sentence specifying that X509_free(3) is NULL-safe, now that we've removed all NULL-checks for it. I should sweep through and add the sentence the rest of the

Re: scheduler: abstract away spc_whichqs

Michal Mazurek wrote: > spc_whichqs is an implementation specific variable of the bsd scheduler. > Abstract it away, easing potential future rewrite. > > This gets rid of curcpu_is_idle() that's used only once, and replaces it > with a more general cpu_is_idle(curcpu()). > > As far as I can tell

Re: malloc: 1st small step in long way to multiple pools

Otto Moerbeek wrote: > a future goal for malloc is to use multiple pools in threaded > environments, to reduce lock contention. > > This is a small first step towards that goal: move two globals to the > pool-specific struct dir_info. Currently there's only a single pool, > but that will change

Probable logic error in st(4)

sys/scsi/st.c:1024 uses: > cmd->len != 0 as a condition. However, cmd is of type struct scsi_rw_tape, and its len field is of type u_int8_t len[3]. Therefore, the condition is always true because len is treated as a pointer. Clang warns about this. Thanks for your time, Mike

Re: head(1) -c

Jeremie Courreges-Anglas wrote: > >> @@ -66,13 +66,18 @@ main(int argc, char *argv[]) > >>argv++; > >>} > >> > >> - while ((ch = getopt(argc, argv, "n:")) != -1) { > >> + while ((ch = getopt(argc, argv, "c:n:")) != -1) { > >>switch (ch) { > >> + case 'c': >

Re: head(1) -c

Jeremie Courreges-Anglas wrote: > Today someone bumped into a port that contained head -c calls. While > upstream could be prodded to care a bit more about portability, support > for head -c is widespread (GNU coreutils, busybox, FreeBSD, NetBSD) so > I don't see any value in being different.

Re: Xorg stipple

Theo de Raadt wrote: > > > Is anyone seriously finding video/Xorg bugs through the default X > > > stipple pattern anymore? Xorg changed the default to draw a black > > > background a while ago (with stipple enabled using the -retro flag), > > > but we have this local change that reverted it

Simplify tcpdump

I think we can assume that people have abs(3) these days... This macro only had one usage, which is visible in the diff. It doesn't look like replacing it should cause any functional changes to the arithmetic. ok? Index: print-icmp6.c

Re: NULL checks of static arrays

Martin Pieuchot wrote: > On 06/03/16(Sun) 19:20, Michael McConville wrote: > > We check static arrays against NULL pretty often in the kernel. I > > suspect most of these are due to recent kernel API changes. Should they > > be removed, or do people want to keep them ar

Re: df(1): replace __progname with getprogname()

ok mmcc@ Michal Mazurek wrote: > Index: bin/df/df.c > === > RCS file: /cvs/src/bin/df/df.c,v > retrieving revision 1.55 > diff -u -p -r1.55 df.c > --- bin/df/df.c 8 Feb 2016 16:23:54 - 1.55 > +++ bin/df/df.c 1

NULL checks of static arrays

We check static arrays against NULL pretty often in the kernel. I suspect most of these are due to recent kernel API changes. Should they be removed, or do people want to keep them around in case the APIs change again? Clang 3.7 warns about them by default, so they're easy to find.

Re: [patch] telnet: stored value never read

frit...@alokat.org wrote: > the value stored in "old" is never read. It's best to leave these unless there's a good reason not to. It probably means that the programmer wanted to maintain the validity of the variable in case we decide to use it later in the function. > Index: sys_bsd.c >

Re: /usr/games/adventure include clean up

ivileged operations*/ > > +#include > #include > +#include > #include > #include > #include > - > #include "extern.h" > #include "hdr.h" > > > > On 03/06/16 12:35, Michael McConville wrote: > >The sys inc

Re: /usr/games/adventure include clean up

The sys includes should be first and separate. See style(9). Edgar Pettijohn wrote: > --- crc.c.origSun Mar 6 10:31:34 2016 > +++ crc.cSun Mar 6 10:31:55 2016 > @@ -33,6 +33,7 @@ > * SUCH DAMAGE. > */ > > +#include > #include "extern.h" > > unsigned long crctab[] = { > ---

Re: cpu.h: parens in macros

Michal Mazurek wrote: > I noticed these macros, I think they should have more parenthesis. I > don't know how to test this though. tentative ok mmcc@ > Index: sys/arch/alpha/include/cpu.h > === > RCS file:

Re: df(1): remove unneeded includes

Theo Buehler wrote: > On Tue, Mar 01, 2016 at 12:37:17PM +0100, Theo Buehler wrote: > > Wasn't this the part of your previous header cleanup that mmcc > > decided not to commit for some reason? > > if mmcc no longer objects, this once more ok tb@ Right, I misunderstood which file this was

tmpfs improvements

* EINVAL is returned in a case where there is insufficient memory. ENOMEM makes more sense. This one is ok natano@. * There wasn't yet a list of possible errors for tmpfs in mount(2). That said, I question the value of maintaining these lists. It's almost impossible for them to be

Re: Correct error number in crypto(9)

Mike Belopuhov wrote: > On 27 February 2016 at 08:21, Michael McConville <mm...@mykolab.com> wrote: > > Michael McConville wrote: > >> Michael McConville wrote: > >> > Does this make sense? > >> > >> I just realized that the allocation fail

Re: Correct error number in crypto(9)

Michael McConville wrote: > Michael McConville wrote: > > Does this make sense? > > I just realized that the allocation failure checks earlier in the > function return ENOBUFS. This probably makes more sense for the sake of > consistency. The best I can tell, the only

Re: Correct error number in crypto(9)

Michael McConville wrote: > Does this make sense? I just realized that the allocation failure checks earlier in the function return ENOBUFS. This probably makes more sense for the sake of consistency. > Index: sys/crypto/crypto

Correct error number in crypto(9)

Does this make sense? Index: sys/crypto/cryptosoft.c === RCS file: /cvs/src/sys/crypto/cryptosoft.c,v retrieving revision 1.80 diff -u -p -r1.80 cryptosoft.c --- sys/crypto/cryptosoft.c 10 Dec 2015 21:00:51 - 1.80 +++

Re: Make alpha 2038-safe

Michael McConville wrote: > Now that we have 64-bit time. Otherwise, all the people running Alpha in > 2038 will yell at us. And sh: Index: arch/sh/sh/clock.c === RCS file: /cvs/src/sys/arch/sh/sh/clock.c,v retrieving revisi

Make alpha 2038-safe

Now that we have 64-bit time. Otherwise, all the people running Alpha in 2038 will yell at us. Index: sys/arch/alpha/alpha/clock.c === RCS file: /cvs/src/sys/arch/alpha/alpha/clock.c,v retrieving revision 1.21 diff -u -p -r1.21

Fix overflow check in sys/netinet6/in6.c

time_second is a time_t, which we define as int64_t. The other operands used are of type uint32_t. Therefore, these checks get promoted to int64_t and the overflow being tested is undefined because it uses signed arithmetic. I think that the below diff fixes the overflow check. However, I'm

Re: Integer overflow in syslogd

Michael Savage wrote: > Here's a patch with less fragile parsing code. Comments inline. > Index: syslogd.c > === > RCS file: /cvs/src/usr.sbin/syslogd/syslogd.c,v > retrieving revision 1.177 > diff -u -p -r1.177 syslogd.c > ---

Re: Integer overflow in syslogd

Michael Savage wrote: > I found an integer overflow in syslogd which can be triggered by > compiling and running: > > #include > #include > #include > > int main( int argc, char ** argv ) { > const char * msg = "<> hello"; > return sendsyslog( msg, strlen( msg ) ); >

Re: df(1) - unneeded headers

Michal Mazurek wrote: > This was ok tb@ but never commited. > > Remove uneeded includes, and sort those that can be sorted (some can't): Committed (mostly). Thanks! I left stdlib.h and unistd.h because I think that C99 requires that those be included when using libc, although failing to do so

Re: [patch] vi enable -pedantic

Jonathan Gray wrote: > I don't think we should enable -pedantic anywhere in the tree. > Different versions of gcc are going to have different ideas of what > pedantic is. This was my reaction too. I like the approach of keeping few to no warnings in default builds. It's easy to "env

Re: iwn firmware error

Stefan Sperling wrote: > On Fri, Feb 05, 2016 at 01:23:18AM -0500, Michael McConville wrote: > > When forcing my laptop to swap, I almost immediately got the following > > firmware error. I'm not sure whether this is expected. Restarting the > > interface brought

Re: pkg_add.1

joshua stein wrote: > We don't recommend FTP mirrors anymore, installing a package via a > pipe doesn't seem to work anymore, and packages have to be signed to > be installed so the advice about miscreants is not very relevant. Good catch with the FTP link. I think it's still worth mentioning

tcpdump CDP crashes

Can E. Acar wrote: > The crashes you posted to icb recently > (https://www.sccs.swarthmore.edu/users/16/mmcconv1/dump/tcpdump-crashes/) > are related to print-cdp.c where the bounds checks are missing/broken. > > The attached diff seems to fix the issues. canacar@ asked me to forward this to the

Re: [patch] kern/exec_script: return error when the shell name is not specified

Mark Kettenis wrote: > > Date: Fri, 5 Feb 2016 13:06:56 -0500 > > From: Michael McConville <mm...@mykolab.com> > > > > Michael McConville wrote: > > > Michael McConville wrote: > > > > Maxim Pugachev wrote: > > > > > In a

Re: dhclient.c patch

Edgar Pettijohn wrote: > --- dhclient.c.origThu Feb 4 17:57:41 2016 > +++ dhclient.cThu Feb 4 17:57:55 2016 > @@ -57,7 +57,6 @@ > #include "privsep.h" > > #include > -#include > #include > #include > > is brought in through dhcpd.h It'd probably be better to add to all

Re: Simplify tcpdump

Michael McConville wrote: > Stuart Henderson wrote: > > On 2016/01/26 20:16, Michael McConville wrote: > > > Stuart Henderson wrote: > > > > On 2016/01/25 22:52, Michael McConville wrote: > > > > > fddi_bitswap is only used once, and it just

Nop null checks in ti(4)

Clang 3.7 warns about this. The rings are arrays, not pointers, so they can't be NULL. ok? Or should these checks be replaced rather than removed? Index: dev/ic/ti.c === RCS file: /cvs/src/sys/dev/ic/ti.c,v retrieving revision 1.22

iwn firmware error

When forcing my laptop to swap, I almost immediately got the following firmware error. I'm not sure whether this is expected. Restarting the interface brought things back to normal. dmesg follows. Feb 5 01:19:04 thinkpad /bsd: iwn0: fatal firmware error Feb 5 01:19:04 thinkpad /bsd: firmware

Re: [PATCH] uname, arch/machine -> %c, %a update in PKG_PATH

Stuart Henderson wrote: > > >> Raf Czlonka wrote: > > >> - ftp.openbsd.org is, AFAIC, overloaded > > Whenever I've checked speeds from ftp.openbsd.org they have been > fairly consistent, this isn't the usual expected behaviour of an > overloaded machine. (not super fast, but they have been

Re: [PATCH] uname, arch/machine -> %c, %a update in PKG_PATH

Raf Czlonka wrote: > - ftp.openbsd.org is, AFAIC, overloaded I haven't been following this thread fully, but I agree that ftp.openbsd.org shouldn't be used in examples. Many many people use the default mirror whenever possible.

Re: Some df(1) cleanup

Theo Buehler wrote: > On Mon, Feb 01, 2016 at 05:17:03PM +0100, Michal Mazurek wrote: > > Meaningful error messages: > > > > mntbuf = calloc(argc, sizeof(struct statfs)); > > if (mntbuf == NULL) > > - err(1, NULL); > > + err(1, "calloc");

Re: less.h small cleanup

Michael Reed wrote: > - sorts includes + remove unneeded comment > - less.h 1.24[1] removes the only use of CHAR_BIT, so remove it Committed. Thanks! > - remove SHELL_META_QUEST, doesn't seem to be used either I'm going to leave this for now because I don't know what it is/was.

Replace less(1)'s stdbool clone with the real McCoy

Does this make sense? Note that screen_crashed can also be 2, so we leave it as an int. Assigning it to TRUE seems to have been a mistake. No binary change, surprisingly. Index: ch.c === RCS file: /cvs/src/usr.bin/less/ch.c,v

Re: _PATH_SENDMAIL in lots of places outside of lpd stuff also

Chris Bennett wrote: > I found a subroutine in printjob.c called sendmail with uses > _PATH_SENDMAIL. > > I found it all over the place: Are you implying that they should be replaced? IIUC, we create a sendmail binary (or at least a link) even though we no longer technically use sendmail. See

Re: _PATH_SENDMAIL in lots of places outside of lpd stuff also

Chris Bennett wrote: > On Fri, Jan 29, 2016 at 09:18:14PM -0500, Michael McConville wrote: > > Chris Bennett wrote: > > > I found a subroutine in printjob.c called sendmail with uses > > > _PATH_SENDMAIL. > > > > > > I found it all over the plac

Re: `ifstated -n' more useful error message

Michael Reed wrote: > If fopen("/etc/ifstated.conf", ...) fails for whatever reason the > error message isn't very helpful: > > $ ifstated -n > ifstated: /etc/ifstated.conf > > With this patch: > > $ ./ifstated -n > ifstated: /etc/ifstated.conf: No such file or directory Committed.

Re: Simplify tcpdump

Stuart Henderson wrote: > On 2016/01/25 22:52, Michael McConville wrote: > > fddi_bitswap is only used once, and it just adds a layer of > > indirection to its preprocessor condition. > > Oh yuk. This is bogus anyway, and there's no good way to handle it. We > dropped sup

Re: Simplify tcpdump

Stuart Henderson wrote: > On 2016/01/26 20:16, Michael McConville wrote: > > Stuart Henderson wrote: > > > On 2016/01/25 22:52, Michael McConville wrote: > > > > fddi_bitswap is only used once, and it just adds a layer of > > > > indirection to its p

Simplify tcpdump

fddi_bitswap is only used once, and it just adds a layer of indirection to its preprocessor condition. This also removes macros for BSDi and Ultrix. ok? Index: print-fddi.c === RCS file: /cvs/src/usr.sbin/tcpdump/print-fddi.c,v

Loops depending on undefined behavior

I've discussed the below with otto@, who thought it was sound but wanted confirmation before I commit. While debugging rarpd(8) for unrelated reasons, I noticed a loop of the following form: > for (i = 1; i; i <<= 1) where i is an int. This relies on shifting into and then out of the sign bit,

Re: Writing Documentation

Timo wrote: > Hi who is responsible for writing documentation for OpenBSD? I'd like > to get involved in writing documentation for OpenBSD as I really like > OpenBSD and I feel technical writing is one of my strong points. In case you (or other readers) need more of an introduction than other

Re: [patch] cleanup vi

Vadim Zhukov wrote: > 2016-01-22 23:18 GMT+03:00 Martijn van Duren > : > > 5) 5_vi_remove_v_strdup.diff: Use strdup instead of v_strdup. > > Not okay: MALLOC macro prints information message to user, while > patched version isn't. I think refactoring shouldn't

Fix nfs_nget() description

Apparently the function was refactored and but the old description remained. I came across this a few weeks ago. Does my revision look good? Index: nfs/nfs_node.c === RCS file: /cvs/src/sys/nfs/nfs_node.c,v retrieving revision 1.62

Proper printf attribute in less(1)

Michael Reed and I noticed the straggling lintism PRINTFLIKE1 in less(1). Should it be replaced with an attribute? If so, am I doing this right? Index: funcs.h === RCS file: /cvs/src/usr.bin/less/funcs.h,v retrieving revision 1.17

Re: [patch] ls + utf-8 support

Martin Natano wrote: > I agree with Ingo, ls(1) shouldn't generate unsafe output. Regardless > of whether the output is to a terminal or some other file. While POSIX is not holy law, doing what you suggest would probably be a violation. See the description of the -q option:

Re: [PATCH] uname, arch/machine -> %c, %a update in PKG_PATH

Raf Czlonka wrote: > Hi all, > > Given that PKG_PATH and pkg.conf(5)'s installpath, now supports %c, %a, > etc. sequences, it might be worth advertising it a bit more by changing > all relevant uname(1), arch(1)/machine(1) occurrences or (hard-coded > release versions or hardware architectures

[less] start simplifying message buffer logic

message is a global static char[2048]. If I understand correctly (I've been playing with this for a while): * message is the user command result message displayed at the bottom (e.g. "Pattern not found (press RETURN)") * message is initialized to all NUL bytes because it's static * the

Re: Simplify less(1) off_t formatting

Nicholas Marriott wrote: > I like the idea, but I don't like calling them ap_off_t and offttoa, > I'd just keep ap_pos and postoa and remove the linenum functions. Does this look good? Index: less.h === RCS file:

Re: gcc typo

Jan Schreiber wrote: > this looks like a typo in gcc. Committed. Thanks! > Index: gnu/gcc/gcc/config/mt/mt.c > === > RCS file: /cvs/src/gnu/gcc/gcc/config/mt/mt.c,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 mt.c > ---

Simplify less(1) off_t formatting

I'm working on bigger simplifications for less's string formatting, but this is a good start. We've removed the off_t aliases for linenums and positions, so we now have two identical sets of off_t formatting and appending functions. The below diff unifies them. As you can see, there is more

Re: [patch] kern/exec_script: return error when the shell name is not specified

Michael McConville wrote: > Maxim Pugachev wrote: > > In a case when the shell name is not specified (i.e. just "#!" without > > a path), don't run the heavy logic that checks shell, simply return > > ENOENT. > > I'm not sure whether this is a reasonable th

Re: [patch] kern/exec_script: return error when the shell name is not specified

Maxim Pugachev wrote: > In a case when the shell name is not specified (i.e. just "#!" without > a path), don't run the heavy logic that checks shell, simply return > ENOENT. I'm not sure whether this is a reasonable thing to do. Someone with more kernel API experience will have to comment. >

Re: allocation simplifications in yacc

Christian Weisgerber wrote: > Christian Weisgerber: > > > The removal of the casts causes a problem in ports/devel/mico, where > > the yacc output is used in C++: > > Also: > graphics/grap > math/aamath > math/logic2cnf ok? Index: skeleton.c

Re: [patch] kern/exec_script: avoid invalid free() in a case of error

Michael McConville wrote: > Michael McConville wrote: > > > On Sun, Dec 13, 2015 at 9:45 PM, Maxim Pugachev <pugachev...@gmail.com> > > > wrote: > > > > Hi, > > > > > > > > In exec_script_makecmds function, when EXEC_HASFD flag w

Re: [patch] kern/exec_script: avoid invalid free() in a case of error

> On Sun, Dec 13, 2015 at 9:45 PM, Maxim Pugachev wrote: > > Hi, > > > > In exec_script_makecmds function, when EXEC_HASFD flag was set, but > > copystr/copyinstr returns an error, we need to set *tmpsap to NULL to > > terminate a loop (under "fail" label) correctly. I

Re: [patch] kern/exec_script: avoid invalid free() in a case of error

Michael McConville wrote: > > On Sun, Dec 13, 2015 at 9:45 PM, Maxim Pugachev <pugachev...@gmail.com> > > wrote: > > > Hi, > > > > > > In exec_script_makecmds function, when EXEC_HASFD flag was set, but > > > copystr/copyinstr returns an er

Re: [PATCH] vi remove custom perr from cl_main

Todd C. Miller wrote: > On Sun, 27 Dec 2015 10:12:23 +0100, Martijn van Duren wrote: > > > This patch has been accepted by the nvi2 project.[1] There are more > > patches, but I'm waiting till these have been reviewed by nvi2. > > Committed, thanks. Thanks for taking care of this. There's a

Re: [patch] nlist(3): out of bounds read

Serguey Parkhomovsky wrote: > Ping? This is the same sanity check that's done in nm(1)'s ELF handling. Make sense to me. Tentative ok mmcc@ Alternatively, this check could be added to __elf_is_ok__, which is called right above where you added it. However, the definition of the function would

Re: [patch] nlist(3): out of bounds read

Michael McConville wrote: > Serguey Parkhomovsky wrote: > > Ping? This is the same sanity check that's done in nm(1)'s ELF handling. > > Make sense to me. Tentative ok mmcc@ > > Alternatively, this check could be added to __elf_is_ok__, which is > called right above whe

Re: ksh.1: Remove $ERRNO reference

Michael Reed wrote: > It's had the ``Not implemented'' notice since ksh.1's initial import > 19 years ago [1], so it's probably not going to be implemented. > > [1]: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/ksh/ksh.1?rev=1.1=text/x-cvsweb-markup Committed. Thanks! bin/ksh/NOTES

Remove redundant continue

A trivial simplification, but it's a false positive for an inner-loop-continue bug, so it'd be nice to take care of it. ok? Index: sys/arch/amd64/amd64/intr.c === RCS file: /cvs/src/sys/arch/amd64/amd64/intr.c,v retrieving revision

Potential continue bug in mii(4)

The continue statement below is a nop. It seems that it meant to continue the outer loop. This is an educated guess based on the logic and the inner loop's comments. Thoughts? Also, in situations like this, should we make all continue statements goto loop_end? In the fix I committed for pciide(4)

Re: Mention lang/go and lang/rust in faq8.html

Michal Mazurek wrote: > Go and Rust are now widely used. It might be worth mentioning them in > the FAQ. ok mmcc@ Thanks! > Index: faq8.html > === > RCS file: /cvs/www/faq/faq8.html,v > retrieving revision 1.268 > diff -u -p

iwn timeouts

I've been running -current on a ThinkPad X201 for close to a year now. iwn times out after about 45-90 seconds every time I boot. This happens very reliably, regardless of which network I'm connecting to. All I get to the syslog is: > Dec 26 17:05:40 thinkpad /bsd: iwn0: timeout waiting for

  1   2   3   >