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
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
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
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
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
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
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
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
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,
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
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-
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
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
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
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 -
@@
15 matches
Mail list logo