Re: install.sub: No need for subshell in feed_random()

2017-07-01 Thread Theo de Raadt
> It agree that it my not seem reasonable enough (to you), but there is a > technical point to it. Well, maybe you'll get to it eventually.

Re: install.sub: No need for subshell in feed_random()

2017-07-01 Thread Klemens Nanni
On Sat, Jul 01, 2017 at 11:17:55PM -0600, Theo de Raadt wrote: On Sat, Jul 01, 2017 at 11:01:00PM -0600, Theo de Raadt wrote: >Don't understand your point. What is this fixing? Nothing gets "fixed", it just avoids unnecessary forking and makes clear that the inner commands do not require a

Re: install.sub: No need for subshell in feed_random()

2017-07-01 Thread Theo de Raadt
> On Sat, Jul 01, 2017 at 11:01:00PM -0600, Theo de Raadt wrote: > >Don't understand your point. What is this fixing? > Nothing gets "fixed", it just avoids unnecessary forking and makes clear > that the inner commands do not require a subshell - there are no side > effects on the environment so

Re: install.sub: No need for subshell in feed_random()

2017-07-01 Thread Klemens Nanni
On Sat, Jul 01, 2017 at 10:13:45PM -0700, Philip Guenther wrote: I've lost track of how many times at work and in OpenBSD I've tested a diff, made a final modification and then committed...a change broken by that final modification. Once you've tested a diff, either don't make a "this is easy!"

Re: install.sub: No need for subshell in feed_random()

2017-07-01 Thread Philip Guenther
On Sat, Jul 1, 2017 at 9:47 PM, Klemens Nanni wrote: > On Sat, Jul 01, 2017 at 09:35:09PM -0700, Philip Guenther wrote: >> >> On Sat, Jul 1, 2017 at 9:27 PM, Klemens Nanni wrote: >>> >>> A simple command list suffices as this is just about redirecting all >>>

Re: install.sub: No need for subshell in feed_random()

2017-07-01 Thread Klemens Nanni
On Sat, Jul 01, 2017 at 11:01:00PM -0600, Theo de Raadt wrote: Don't understand your point. What is this fixing? Nothing gets "fixed", it just avoids unnecessary forking and makes clear that the inner commands do not require a subshell - there are no side effects on the environment so a

Re: file: replace fgetln with getline(3)

2017-07-01 Thread Bryan Steele
On Sat, Jul 01, 2017 at 08:48:18PM -0400, Bryan Steele wrote: > On Sat, Jul 01, 2017 at 06:53:29PM -0400, Bryan Steele wrote: > > On Sun, Jul 02, 2017 at 12:26:19AM +0200, Ingo Schwarze wrote: > > > I don't see a need for two char * variables here, that's an artifact > > > of the typical fgetln(3)

Re: install.sub: No need for subshell in feed_random()

2017-07-01 Thread Theo de Raadt
Don't understand your point. What is this fixing? > A simple command list suffices as this is just about redirecting all > output at once. > > Feedback/OK? > > Index: install.sub > === > RCS file:

Re: install.sub: No need for subshell in feed_random()

2017-07-01 Thread Klemens Nanni
On Sat, Jul 01, 2017 at 09:35:09PM -0700, Philip Guenther wrote: On Sat, Jul 1, 2017 at 9:27 PM, Klemens Nanni wrote: A simple command list suffices as this is just about redirecting all output at once. Feedback/OK? ... + {dmesg; cat $CGI_INFO /*.conf; sysctl; route

Re: install.sub: No need for subshell in feed_random()

2017-07-01 Thread Philip Guenther
On Sat, Jul 1, 2017 at 9:27 PM, Klemens Nanni wrote: > A simple command list suffices as this is just about redirecting all > output at once. > > Feedback/OK? ... > + {dmesg; cat $CGI_INFO /*.conf; sysctl; route -n show; df; This code has not been tested (and does not

ifstated unused variable

2017-07-01 Thread Rob Pierce
Remove unused variable from header file. Index: ifstated.h === RCS file: /cvs/src/usr.sbin/ifstated/ifstated.h,v retrieving revision 1.12 diff -u -p -r1.12 ifstated.h --- ifstated.h 28 Jun 2017 11:10:08 - 1.12 +++

install.sub: No need for subshell in feed_random()

2017-07-01 Thread Klemens Nanni
A simple command list suffices as this is just about redirecting all output at once. Feedback/OK? Index: install.sub === RCS file: /cvs/src/distrib/miniroot/install.sub,v retrieving revision 1.1016 diff -u -p -r1.1016 install.sub

ifstated whitespace var assignment diff

2017-07-01 Thread Rob Pierce
Remove variable assignment in declaration and add whitespace to improve readability. No functional change. Rob Index: ifstated.c === RCS file: /cvs/src/usr.sbin/ifstated/ifstated.c,v retrieving revision 1.45 diff -u -p -r1.45

tee: Replace hand-rolled list with SLIST_*

2017-07-01 Thread Klemens Nanni
No functional change or bugfix but queue(3) is the for a reason. That way the code even is a tad clearer to me (and two lines shorter). Feedback/OK? Index: tee.c === RCS file: /cvs/src/usr.bin/tee/tee.c,v retrieving revision 1.11

Re: file: replace fgetln with getline(3)

2017-07-01 Thread Bryan Steele
On Sat, Jul 01, 2017 at 06:53:29PM -0400, Bryan Steele wrote: > On Sun, Jul 02, 2017 at 12:26:19AM +0200, Ingo Schwarze wrote: > > I don't see a need for two char * variables here, that's an artifact > > of the typical fgetln(3) complications. Just > > > > char*line = NULL; > >

Re: brconfig: Unify/fix strtoul(3) handling

2017-07-01 Thread Klemens Nanni
On Sun, Jul 02, 2017 at 01:09:19AM +0100, Ricardo Mestre wrote: You're blindly replacing strtoul with strtonum without taking the base 0 into account. I'd recommend you take a look at strtoul's manpage first and check what using base 0 means (strtonum always use base 10). Don't worry, I can

almost inlined bus space

2017-07-01 Thread Artturi Alm
Hi, so i was bored, and decided to see, if i could revive an old diff of mine, which does separate bus_dma.h out of arm/include/bus.h, and mostly inlines the rest in armv7/include/bus.h (credit for the idea of inlining bus space goes to miod@). the diff below might not be absolutely complete, i

Re: brconfig: Unify/fix strtoul(3) handling

2017-07-01 Thread Ted Unangst
Ricardo Mestre wrote: > Of course the diff still may make sense if working with different bases, > apart from 10, is not required anymore. i had a glance through and didn't see any that made sense to keep support for octal or hex. was hoping a more serious brconfig user would also take a look at

Re: brconfig: Unify/fix strtoul(3) handling

2017-07-01 Thread Ricardo Mestre
Of course the diff still may make sense if working with different bases, apart from 10, is not required anymore. On 01:09 Sun 02 Jul , Ricardo Mestre wrote: > Hi Klemens, > > You're blindly replacing strtoul with strtonum without taking the base 0 > into account. > > I'd recommend you take

Re: brconfig: Unify/fix strtoul(3) handling

2017-07-01 Thread Ricardo Mestre
Hi Klemens, You're blindly replacing strtoul with strtonum without taking the base 0 into account. I'd recommend you take a look at strtoul's manpage first and check what using base 0 means (strtonum always use base 10). Best regards, mestre

Re: brconfig: Unify/fix strtoul(3) handling

2017-07-01 Thread Klemens Nanni
On Fri, Jun 09, 2017 at 08:33:16PM +0200, Klemens Nanni wrote: No need for temporary variables either, strtonum guarantees through maxval that its return value won't overflow when casted. Index: brconfig.c === RCS file:

Re: file: replace fgetln with getline(3)

2017-07-01 Thread Bryan Steele
On Sun, Jul 02, 2017 at 12:26:19AM +0200, Ingo Schwarze wrote: > I don't see a need for two char * variables here, that's an artifact > of the typical fgetln(3) complications. Just > > char*line = NULL; > size_t linesize = 0; > ssize_t slen; > > while ((slen =

Re: file: replace fgetln with getline(3)

2017-07-01 Thread Ingo Schwarze
Hi, Nicholas Marriott wrote on Sat, Jul 01, 2017 at 09:48:08PM +0100: > Safer how? 1. fgetln(3) returns a char array that is not NUL-terminated. That is prone to buffer overrun bugs in general. getline(3) always returns proper NUL-terminated C strings. 2. The array returned from

rename variable in ifstated

2017-07-01 Thread Rob Pierce
never.never say always.always. Rename one of the "always" variables to "body" for improved readability. No functional change. >From ifstated.conf(5): "Each state consistes of an init block and a body. The init block is used to initialize the state and is executed each time the state is

Re: file: replace fgetln with getline(3)

2017-07-01 Thread Nicholas Marriott
Right but we are already taking that into account, that is not a problem here. Anyway, change it if you like, it is shorter anyway. On Sat, Jul 01, 2017 at 05:03:41PM -0400, Bryan Steele wrote: > On Sat, Jul 01, 2017 at 09:48:08PM +0100, Nicholas Marriott wrote: > > Safer how? > > I believe

Re: file: replace fgetln with getline(3)

2017-07-01 Thread Bryan Steele
On Sat, Jul 01, 2017 at 09:48:08PM +0100, Nicholas Marriott wrote: > Safer how? I believe that's in reference to the CAVEATS mentioned in fgetln(3). http://man.openbsd.org/fgetln.3#CAVEATS getline(3) returns C strings. > I don't mind too much, but you will also need to initialize size to 0 >

Re: file: replace fgetln with getline(3)

2017-07-01 Thread Nicholas Marriott
Safer how? I don't mind too much, but you will also need to initialize size to 0 (it is currently uninitialized) before calling getline(). On Sat, Jul 01, 2017 at 04:35:39PM -0400, Bryan Steele wrote: > On Sat, Jul 01, 2017 at 09:27:47PM +0100, Nicholas Marriott wrote: > > > > What is the

Re: file: close fd after test_file

2017-07-01 Thread Nicholas Marriott
I'm not sure I see much point in this but do it if you like. It will potentially close STDIN_FILENO though, I think that is harmless at the moment - or perhaps prepare_input should dup() it. On Sat, Jul 01, 2017 at 03:26:27PM -0400, Bryan Steele wrote: > I think I lost this part in my larger

Re: file: replace fgetln with getline(3)

2017-07-01 Thread Bryan Steele
On Sat, Jul 01, 2017 at 09:27:47PM +0100, Nicholas Marriott wrote: > > What is the point of doing this? fgetln works fine. > There's been other examples of commits replacing fgetln for getline, while portability isn't a major concern, it's been suggested that getline may be safer.

Re: file: replace fgetln with getline(3)

2017-07-01 Thread Nicholas Marriott
What is the point of doing this? fgetln works fine. On Sat, Jul 01, 2017 at 02:47:25PM -0400, Bryan Steele wrote: > Seems to work, does this look right? > > -Bryan. > > Index: magic-load.c > === > RCS file:

file: close fd after test_file

2017-07-01 Thread Bryan Steele
I think I lost this part in my larger diff, make sure fds are closed after testing files. -Bryan. Index: file.c === RCS file: /cvs/src/usr.bin/file/file.c,v retrieving revision 1.63 diff -u -p -u -r1.63 file.c --- file.c 28 Jun

Re: kernel relinking

2017-07-01 Thread Ax0n
I haven't been paying attention to mail on these LDOMs. Thanks for the heads up. Output looks good. >From r...@puffyfive.ldom.openbsd.local Sat Jul 1 14:07:05 2017 Delivered-To: r...@puffyfive.ldom.openbsd.local From: Charlie Root To:

Re: kernel relinking

2017-07-01 Thread Theo de Raadt
> I've put the snapshot LDOM through some paces with each snapshot: high CPU > load, networking, and heavy filesystem utilization. It's every bit as solid > as the other LDOMs. I have only seen the "relinking" message at the end of > snapshot upgrades, but due to /bsd changing upon each reboot, I

Re: netstat(1) print PID for sockets.

2017-07-01 Thread Sebastian Benoit
Sebastian Benoit(be...@openbsd.org) on 2017.07.01 20:40:17 +0200: > Sebastian Benoit(be...@openbsd.org) on 2017.07.01 16:44:14 +0200: > > This makes netstat show only listening sockets for tcp sockets > > when invoked as netstat -l. > > > > With it "netstat -l -finet -p tcp" is equivalent to > >

Re: kernel relinking

2017-07-01 Thread Ax0n
sparc64 snapshots, run inside an LDOM. Primary domain and the other 6 LDOMs are 6.1-STABLE. I've put the snapshot LDOM through some paces with each snapshot: high CPU load, networking, and heavy filesystem utilization. It's every bit as solid as the other LDOMs. I have only seen the "relinking"

file: replace fgetln with getline(3)

2017-07-01 Thread Bryan Steele
Seems to work, does this look right? -Bryan. Index: magic-load.c === RCS file: /cvs/src/usr.bin/file/magic-load.c,v retrieving revision 1.25 diff -u -p -r1.25 magic-load.c --- magic-load.c1 Jul 2017 14:34:29 - 1.25

netstat(1) print PID for sockets.

2017-07-01 Thread Sebastian Benoit
Sebastian Benoit(be...@openbsd.org) on 2017.07.01 16:44:14 +0200: > This makes netstat show only listening sockets for tcp sockets > when invoked as netstat -l. > > With it "netstat -l -finet -p tcp" is equivalent to > "netstat -a -finet | grep LISTEN" > > I (re)used -l because Linux has the

HEADS-UP: no-depends is in

2017-07-01 Thread Marc Espie
This follows on the footsteps of guenther@, who did a similar job in the kernel. Basically, the old-style "make depend, then make all" bsd makefile pattern is GONE. More accurately, dependencies are now generated on the fly using gcc and clang's -M* options. Instead of a "magical" .depend file,

netstat(1) show only listening sockets

2017-07-01 Thread Sebastian Benoit
This makes netstat show only listening sockets for tcp sockets when invoked as netstat -l. With it "netstat -l -finet -p tcp" is equivalent to "netstat -a -finet | grep LISTEN" I (re)used -l because Linux has the same option. FreeBSD does not have -l, but it does not error out when invoked with

Re: small patch for file(1)

2017-07-01 Thread Nicholas Marriott
ok nicm, it should not fclose this because it didn't open it On Sat, Jul 01, 2017 at 10:19:32AM -0400, Bryan Steele wrote: > magic_load() is only called in main and fcloses magicfp immediately, > this removes a redundant fclose. > > Index: magic-load.c >

small patch for file(1)

2017-07-01 Thread Bryan Steele
magic_load() is only called in main and fcloses magicfp immediately, this removes a redundant fclose. Index: magic-load.c === RCS file: /cvs/src/usr.bin/file/magic-load.c,v retrieving revision 1.24 diff -u -p -u -r1.24 magic-load.c

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

2017-07-01 Thread kshe
On Tue, 27 Jun 2017 09:29:10 +, 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. > >

Re: no-depends for real, the juicy part

2017-07-01 Thread Marc Espie
Almost certainly the last version. A less used architecture met with a snag, because libsa/Makefile.inc uses depend:: which got make to barf out as target: and target:: don't mesh. Apart from that, I've got tb@'s okay, and krw@ seemed happy as well... further comments should happen about

Re: arm/sysreg.h use in C

2017-07-01 Thread Artturi Alm
Hi, just in case i didn't make it clear what it is for, here's diff "fixing" current uses below, compile-tested. -Artturi diff --git a/sys/arch/arm/arm/cpufunc.c b/sys/arch/arm/arm/cpufunc.c index c91108e7066..fcb56627af7 100644 --- a/sys/arch/arm/arm/cpufunc.c +++ b/sys/arch/arm/arm/cpufunc.c