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

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 fuse-exfat and then deleting it > > > > again without first unmounting the file

Re: __warn_references: drop redundant "warning: " prefix

On Sun, Nov 12 2017, Scott Cheloha wrote: > Hi, > > GNU ld has prefixed the contents of .gnu.warning.SYMBOL sections > with "warning: " since 2003, so the messages themselves need not > contain the prefix anymore. > > If LLVM ld ever acknowledges .gnu.warning sections I

Re: hide wpakey from root by default

Stefan Sperling wrote: > Or is modifying ifconfig sufficient? > We are more concerned about textual display rather than the > kernel/userland ioctl boundary, correct? > > The option list for ifconfig is [-AaC]. Plenty of letters available. > We could add: > >-P Show authentication details

permit IPV6_V6ONLY in sockopt()

Hi, I ran into a pledge'ing weirdness with Go apps and 'inet'. Go tries to probe available communication options: https://github.com/golang/go/blob/master/src/net/ipsock_posix.go#L44-L56 The result of which ends up being 'inet' pledged go apps fail with: 'pledge "inet", syscall 105' Removing

Re: relayd status code handling

Hi! I have 4 digit number of relayd instances and I'v seen plenty of such products. ownCloud, Nextcloud and some Atlassian products to name few. relayd seems to be the only one to enforce the RFC so strictly. I'd be glad if this gets relaxed a bit. Rivo On Fri, 2017-11-17 at 18:52 +0100,

Re: pppd: explicit_bzero sensitive buffers

> On Nov 17, 2017, at 3:07 PM, Stuart Henderson wrote: > > On 2017/11/17 21:55, Jeremie Courreges-Anglas wrote: >> On Sat, Nov 11 2017, Scott Cheloha wrote: >>> Hi, >>> >>> You want explicit_bzero(3) for these buffers. >>> >>> Zeroing a buffer is

Re: pppd: explicit_bzero sensitive buffers

On Sat, Nov 11 2017, Scott Cheloha wrote: > Hi, > > You want explicit_bzero(3) for these buffers. > > Zeroing a buffer is compiler- and system-dependent, so I added a > new macro. I have committed the fixed version, with the macro. > I'll send a pull request upstream if

Re: faster printf

> So C99 explicitly requires failure *for encoding errors* and > explicitly requires multibyte encoding for the format string. > So it appears that *everybody* (except us) is in blatant violation > of C99. > > To hell with multibyte characters! How on earth do so many dragons > fit into such a

Re: faster printf

> Todd's research revealed that jtc@ got the information from the > C standard in 1995, so i just checked what C89 (sic!) says: > > 4.9.6.1 The fprintf function > [...] > The format shall be a multibyte character sequence, beginning and > ending in its initial shift state. The format is

Re: faster printf

Hi Theo, Theo de Raadt wrote on Fri, Nov 17, 2017 at 10:43:10AM -0700: > Ingo Schwarze wrote: >> I don't think, though, that the commit message should advertise >> this as a performance improvement. It should be called an intentional >> change of behaviour, now using the format string as a byte

relayd status code handling

Hi, relayd enforces a rule in rfc section 3.3.2: rfc 7230 3.3 Message Body All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses do not include a message body. All other responses do include a message body, although the body might be of zero length. rfc 7230

Re: faster printf

> I don't think, though, that the commit message should advertise > this as a performance improvement. It should be called an intentional > change of behaviour, now using the format string as a byte string > like everyone else, no matter whether POSIX explicitly specifies > it as a character

Re: faster printf

On Fri, 17 Nov 2017 10:20:49 -0700, "Todd C. Miller" wrote: > I've done a brief survey using the test program at the end of > this message. Here are the results: Here's the missing test program. It compares how mbrtowc() and snprintf() treat an invalid UTF-8 sequence. I chose a simple one.

Re: faster printf

Ingo Schwarze wrote on Fri, Nov 17, 2017 at 03:07:48PM +0100: [ regarding cases where this may matter in practice ] > (2) Programs legitimately calling *printf() with a variable format > string in any non-POSIX locale, even if it's just UTF-8. Whoa. I just realized there is a very

Re: faster printf

> On Thu, 16 Nov 2017 11:27:45 -0700, "Theo de Raadt" wrote: > > > Yes, I already proposed that someone made a mistake a while ago. > > This was added in NetBSD in 1995: > > > revision 1.17 > date: 1995/05/02 19:52:41; author: jtc; state: Exp; lines: +15 -8; >

Re: faster printf

On Thu, 16 Nov 2017 11:27:45 -0700, "Theo de Raadt" wrote: > Yes, I already proposed that someone made a mistake a while ago. This was added in NetBSD in 1995: revision 1.17 date: 1995/05/02 19:52:41; author: jtc; state: Exp; lines: +15 -8; The C Standard says

Re: ifconfig gif0 deletetunnel is different

On Fri, Nov 17, 2017 at 04:51:55PM +0100, Sebastian Benoit wrote: > ok? OK bluhm@ with a nit > +.It Cm -tunnel Ar src_address dest_address > +Remove the source and destination tunnel addresses. -tunnel does not take arguments

ifconfig gif0 deletetunnel is different

ifconfig deletetunnel is different from other ifconfig commands, as others have options "something" and "-something". Here i add "-tunnel" and keep "deletetunnel", but undocumented to be removed 2 releases hence. I would update current.html with this. ok? (benno_ifconfig_tunnel2.diff) diff

Re: hide wpakey from root by default

On Fri, Nov 17, 2017 at 01:20:53PM -, Christian Weisgerber wrote: > On 2017-11-17, Stefan Sperling wrote: > > > This diff makes the WPA key available only if the interface is in > > debug mode (suggestion by phessler). If this is acceptable then I > > can also try to squeeze

Re: hide wpakey from root by default

On 2017-11-17, Stefan Sperling wrote: > This diff makes the WPA key available only if the interface is in > debug mode (suggestion by phessler). If this is acceptable then I > can also try to squeeze a hint into the ifconfig man page so that > this mechanism can be discovered by

Re: add an iqdrops view to systat to show interface queue drops

On 2017-11-17, David Gwynne wrote: > can we have modified displays within a view? We already have this for the ifstat view. The character B changes the counter view between bytes and bits. Pressing b displays statistics as calculated from boot

Re: hide wpakey from root by default

On Fri, Nov 17 2017, Stefan Sperling wrote: > There have been several instances of people mailing out WPA keys as > part of ifconfig output, e.g. in bug reports. This happens when you > run ifconfig as root and copy/paste without thinking. > > I see no real need to ever show the

Re: hide wpakey from root by default

Stefan Sperling(s...@stsp.name) on 2017.11.17 11:41:57 +0100: > There have been several instances of people mailing out WPA keys as > part of ifconfig output, e.g. in bug reports. This happens when you > run ifconfig as root and copy/paste without thinking. > > I see no real need to ever show the

Re: hide wpakey from root by default

On Fri, Nov 17, 2017 at 11:41:57AM +0100, Stefan Sperling wrote: > There have been several instances of people mailing out WPA keys as > part of ifconfig output, e.g. in bug reports. This happens when you > run ifconfig as root and copy/paste without thinking. > > I see no real need to ever show

hide wpakey from root by default

There have been several instances of people mailing out WPA keys as part of ifconfig output, e.g. in bug reports. This happens when you run ifconfig as root and copy/paste without thinking. I see no real need to ever show the key except in circumstances where the key needs to be legitimately

armv7/man4: sxitimer.4 small update

Hi, variations of this timer "IP" can be found from all sunxis i've seen, but let's add only the few where this is actually used now, instead of keeping A20 listed. Hopefully the addition of agtimer timer to the description makes sense too :) -Artturi diff --git

Re: clang: Avoid EBX/RBX

On Fri, Nov 17, 2017 at 08:46:28AM +, Stuart Henderson wrote: > On 2017/11/17 09:36, Antoine Jacoutot wrote: > > > here are. Personally I'd like to see devel/libexecinfo to be removed > > > from ports if possible. > > > > +1 > > I even volunteer to do that part. > > AFAIK it's not a *hard*

Re: clang: Avoid EBX/RBX

On 2017/11/17 09:36, Antoine Jacoutot wrote: > > here are. Personally I'd like to see devel/libexecinfo to be removed > > from ports if possible. > > +1 > I even volunteer to do that part. > AFAIK it's not a *hard* requirement for anything. It would actually be easier not to have it,

Re: clang: Avoid EBX/RBX

> here are. Personally I'd like to see devel/libexecinfo to be removed > from ports if possible. +1 I even volunteer to do that part. AFAIK it's not a *hard* requirement for anything. -- Antoine

man4/openprom.4: striking ioctl

Hi, highly visible outside the default output, ie. here: https://man.openbsd.org/openprom -Artturi diff --git a/share/man/man4/man4.macppc/openprom.4 b/share/man/man4/man4.macppc/openprom.4 index 1f5145c578f..580caaea517 100644 --- a/share/man/man4/man4.macppc/openprom.4 +++

Re: Tweak OF_getnodebyname()

On Thu, Nov 16, 2017 at 09:39:20PM +0100, Mark Kettenis wrote: > The current FDT implementation is fairly useless since it doesn't > actually look at the child nodes. The macppc implementation walks the > entire tree. But all current use cases of this function only look at > children of the

Re: athn(4) USB open firmware support

On Fri, Nov 17, 2017 at 12:28:35AM +0100, Stefan Sperling wrote: > > This diff switches athn(4) USB devices to open source firmware. > > I only have an AR9271 device which I can test with: > athn0 at uhub1 port 2 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev > 2.00/1.08 addr 3 > athn0: