[Patch] Relocate a vmctl entry in 69.html

2021-04-18 Thread Ross L Richardson
It probably belongs with the other vmctl entry rather than under userland networking changes... Ross Index: 69.html === RCS file: /cvs/www/69.html,v retrieving revision 1.53 diff -u -p -r1.53 69.html --- 69.html 18 Apr 2021

[Patch] Typo ("it's" should be "its") in 69.html

2021-04-18 Thread Ross L Richardson
Just an incorrect possessive form... Ross Index: 69.html === RCS file: /cvs/www/69.html,v retrieving revision 1.53 diff -u -p -r1.53 69.html --- 69.html 18 Apr 2021 12:08:06 - 1.53 +++ 69.html 19 Apr 2021 04:25:56

Re: printf(1): support \u and \U

2021-04-18 Thread Martijn van Duren
On Sun, 2021-04-18 at 22:53 +0200, Martijn van Duren wrote: > On Sun, 2021-04-18 at 17:52 +0200, Martijn van Duren wrote: > > I'm always frustrated when a unicode character question comes up and I > > have to look up the UTF-8 byte sequence to reproduce it. When fixing \x > > I found the \u and \U

Re: printf(1) Fix hex numbers

2021-04-18 Thread Martijn van Duren
On Sun, 2021-04-18 at 12:38 -0900, Philip Guenther wrote: > On Sun, Apr 18, 2021 at 12:04 PM Martijn van Duren > wrote: > > On Sun, 2021-04-18 at 11:17 -0900, Philip Guenther wrote: > > > > > > I'll just throw in a note that the current POSIX spec does not include > > > support for \x in the

Re: printf(1) Fix hex numbers

2021-04-18 Thread Philip Guenther
On Sun, Apr 18, 2021 at 12:04 PM Martijn van Duren < openbsd+t...@list.imperialat.at> wrote: > On Sun, 2021-04-18 at 11:17 -0900, Philip Guenther wrote: > > > > I'll just throw in a note that the current POSIX spec does not include > support for \x in the printf(1) format or in the argument to

Re: printf(1) Fix hex numbers

2021-04-18 Thread Martijn van Duren
On Sun, 2021-04-18 at 11:17 -0900, Philip Guenther wrote: > > I'll just throw in a note that the current POSIX spec does not include > support for \x in the printf(1) format or in the argument to the %b format > specifier.  At least for \x in the format string it > appears to require that it

Re: printf(1): support \u and \U

2021-04-18 Thread Martijn van Duren
On Sun, 2021-04-18 at 17:52 +0200, Martijn van Duren wrote: > I'm always frustrated when a unicode character question comes up and I > have to look up the UTF-8 byte sequence to reproduce it. When fixing \x > I found the \u and \U escape sequences in gprintf, which seem mighty > handy for this

Re: printf(1) Fix hex numbers

2021-04-18 Thread Philip Guenther
I'll just throw in a note that the current POSIX spec does not include support for \x in the printf(1) format or in the argument to the %b format specifier. At least for \x in the format string it appears to require that it _not_ be interpreted, such that printf '\x61\n' must output \x61

Re: printf(1) Fix hex numbers

2021-04-18 Thread Martijn van Duren
On Thu, 2021-04-15 at 19:48 -0600, Todd C. Miller wrote: > On Fri, 16 Apr 2021 03:34:04 +0200, Martijn van Duren wrote: > > > We currently have NetBSD's behaviour when it comes to to no characters, > > so no need to change there imho, but the 2 character limit seems like > > a good place to stop,

printf(1): support \u and \U

2021-04-18 Thread Martijn van Duren
I'm always frustrated when a unicode character question comes up and I have to look up the UTF-8 byte sequence to reproduce it. When fixing \x I found the \u and \U escape sequences in gprintf, which seem mighty handy for this exact case. My implementation differs from gprintf in that leading

citrus_none: don't allow codepoints > 0x7f

2021-04-18 Thread Martijn van Duren
Hello tech@, Currently we accept codepoints 0-0xff in citrus_none, but the C/POSIX locale use 7 bit ascii, allowing us currently to return unspecified values. From code-inspection, NetBSD does the same thing we do (since they also use citrus, that's to be expected), but FreeBSD (from code-

Re: Incomplete sentence in 69.html

2021-04-18 Thread Stefan Sperling
On Sun, Apr 18, 2021 at 09:58:41PM +1000, Ross L Richardson wrote: > Under "IEEE 802.11 wireless stack improvements and bugfixes:", an item > appears to have been truncated... > "Fixed automatic selection of the 11a/b/g/n/ac operating mode when" > > Ross > > I've fixed this. Thanks for

Incomplete sentence in 69.html

2021-04-18 Thread Ross L Richardson
Under "IEEE 802.11 wireless stack improvements and bugfixes:", an item appears to have been truncated... "Fixed automatic selection of the 11a/b/g/n/ac operating mode when" Ross

[Patch] "usb" ==> "USB" for consistency

2021-04-18 Thread Ross L Richardson
Probably! Ross Index: 69.html === RCS file: /cvs/www/69.html,v retrieving revision 1.52 diff -u -p -r1.52 69.html --- 69.html 17 Apr 2021 20:45:22 - 1.52 +++ 69.html 18 Apr 2021 11:19:14 - @@ -424,7 +424,7

[Patch] Fix mangled sentence in 69.html (apmd control socket)

2021-04-18 Thread Ross L Richardson
Simplest fix below. Ross Index: 69.html === RCS file: /cvs/www/69.html,v retrieving revision 1.52 diff -u -p -r1.52 69.html --- 69.html 17 Apr 2021 20:45:22 - 1.52 +++ 69.html 18 Apr 2021 11:05:33 - @@