Re: Detect more keyboard cases when starting X

[Matthieu Herrb]

On Sat, Dec 26, 2015 at 10:42:10PM +0500, Alexandr Shadchin wrote:
> On Fri, Dec 25, 2015 at 05:55:22PM -0700, Anthony J. Bentley wrote:
> > Hi,
> > 
> > As X starts, it will attempt to detect features from the kbd(8)
> > setting--for example, us.dvorak will enable dvorak in X, and
> > fr.dvorak will enable French dvorak in X. However, it detects
> > these features with equality checks, which will fail if multiple
> > options are set, as in the case of us.dvorak.swapctrlcaps or
> > fr.dvorak.swapctrlcaps.
> > 
> > Instead of checking for equality, this diff instead checks if the
> > bits are set. Now us.dvorak.swapctrlcaps and fr.dvorak.swapctrlcaps
> > work, us.swapctrlcaps.iopener swaps ctrl/caps, and the ones that
> > already worked (de.nodead, etc) still do.
> > 
> > This was reported on misc@ by "Sevan / Venture37" back in June.
> > 
> > ok?
> > 
> 
> ok shadchin@

It looks ok to me too. ok matthieu@. 

> 
> > Index: config/wscons.c
> > ===
> > RCS file: /cvs/xenocara/xserver/config/wscons.c,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 wscons.c
> > --- config/wscons.c 15 Jan 2015 01:30:40 -  1.14
> > +++ config/wscons.c 25 Dec 2015 21:37:21 -
> > @@ -139,7 +139,7 @@ wscons_add_keyboard(void)
> >  break;
> >  }
> >  for (i = 0; kbdvar[i].val; i++)
> > -if (wsenc == kbdvar[i].val || KB_VARIANT(wsenc) == kbdvar[i].val) {
> > +if ((wsenc & kbdvar[i].val) == kbdvar[i].val) {
> >  LogMessageVerb(X_INFO, 3, "wskbd: using variant %s\n",
> > kbdvar[i].name);
> >  input_options = input_option_new(input_options,
> > @@ -147,7 +147,7 @@ wscons_add_keyboard(void)
> >  break;
> >  }
> >  for (i = 0; kbdopt[i].val; i++)
> > -if (KB_VARIANT(wsenc) == kbdopt[i].val) {
> > +if (KB_VARIANT(wsenc) & kbdopt[i].val) {
> >  LogMessageVerb(X_INFO, 3, "wskbd: using option %s\n",
> > kbdopt[i].name);
> >  input_options = input_option_new(input_options,
> > 
> 
> -- 
> Alexandr Shadchin

-- 
Matthieu Herrb


pgpXGvjUkK3j0.pgp
Description: PGP signature

Re: remove #ifndef MKNOD from ksh(1) and enforce pledge(2) on all codepaths

[Ricardo Mestre]

Please disregard this for now, -m (extended permissions) won't work this way

Thanks for the tip tb@
On 18:33 Sat 26 Dec , Ricardo Mestre wrote:
> Or even better keep the #ifndef since mknod(8) already has dpath annotation:
> 
> Index: main.c
> ===
> RCS file: /cvs/src/bin/ksh/main.c,v
> retrieving revision 1.75
> diff -u -p -u -r1.75 main.c
> --- main.c  14 Dec 2015 13:59:42 -  1.75
> +++ main.c  26 Dec 2015 18:31:45 -
> @@ -160,6 +160,12 @@ main(int argc, char *argv[])
> perror("pledge");
> exit(1);
> }
> +#else
> +   if (pledge("stdio rpath wpath cpath dpath fattr flock getpw proc exec 
> tty",
> +   NULL) == -1) {
> +   perror("pledge");
> +   exit(1);
> +   }
>  #endif
> 
> On 18:28 Sat 26 Dec , Ricardo Mestre wrote:
> > Hi tech@
> > 
> > Now that dpath annotation in pledge(2) is available then #ifndef MKNOD can 
> > be
> > removed and enforce pledge(2) on all codepaths, is this correct, comments?
> > 
> > Index: main.c
> > ===
> > RCS file: /cvs/src/bin/ksh/main.c,v
> > retrieving revision 1.75
> > diff -u -p -u -r1.75 main.c
> > --- main.c  14 Dec 2015 13:59:42 -  1.75
> > +++ main.c  26 Dec 2015 18:23:34 -
> > @@ -154,13 +154,11 @@ main(int argc, char *argv[])
> >  
> > kshname = argv[0];
> >  
> > -#ifndef MKNOD
> > -   if (pledge("stdio rpath wpath cpath fattr flock getpw proc exec 
> > tty",
> > +   if (pledge("stdio rpath wpath cpath dpath fattr flock getpw proc 
> > exec tty",
> > NULL) == -1) {
> > perror("pledge");
> > exit(1);
> > }
> > -#endif
> >  
> > ainit();  /* initialize permanent Area */
> >  

Re: remove #ifndef MKNOD from ksh(1) and enforce pledge(2) on all codepaths

[Theo de Raadt]

No thanks.  I don't want my shell able to intrinsically create
nodes. Let's keep it as it is.

Or even better keep the #ifndef since mknod(8) already has dpath 
annotation:

Index: main.c
===
RCS file: /cvs/src/bin/ksh/main.c,v
retrieving revision 1.75
diff -u -p -u -r1.75 main.c
--- main.c  14 Dec 2015 13:59:42 -  1.75
+++ main.c  26 Dec 2015 18:31:45 -
@@ -160,6 +160,12 @@ main(int argc, char *argv[])
perror("pledge");
exit(1);
}
+#else
+   if (pledge("stdio rpath wpath cpath dpath fattr flock getpw 
proc exec tty",
+   NULL) == -1) {
+   perror("pledge");
+   exit(1);
+   }
 #endif

infinite loop in randomread()/randomwrite()

[Martin Natano]

A read of 2^32 bytes can trigger an endless loop in randomread(), due to
integer truncation when passing a size_t argument to min(). There is a
similar issue in randomwrite().

The diff included below is a minimal version of a similar diff I've sent
to tech@ some months ago, but with peripheral changes, like converting
uiomovei() to uiomove() or adding unnecessary casts, removed. This
should make the diff easier to review.

See http://marc.info/?l=openbsd-tech=142850699715734 for reference.

Index: dev/rnd.c
===
RCS file: /cvs/src/sys/dev/rnd.c,v
retrieving revision 1.176
diff -u -p -r1.176 rnd.c
--- dev/rnd.c   27 Oct 2015 11:13:06 -  1.176
+++ dev/rnd.c   26 Dec 2015 10:26:09 -
@@ -840,7 +840,7 @@ randomread(dev_t dev, struct uio *uio, i
}
 
while (ret == 0 && uio->uio_resid > 0) {
-   int n = min(POOLBYTES, uio->uio_resid);
+   int n = ulmin(POOLBYTES, uio->uio_resid);
 
if (myctx) {
 #ifndef KEYSTREAM_ONLY
@@ -872,7 +872,7 @@ randomwrite(dev_t dev, struct uio *uio, 
buf = malloc(POOLBYTES, M_TEMP, M_WAITOK);
 
while (ret == 0 && uio->uio_resid > 0) {
-   int n = min(POOLBYTES, uio->uio_resid);
+   int n = ulmin(POOLBYTES, uio->uio_resid);
 
ret = uiomovei(buf, n, uio);
if (ret != 0)


cheers,
natano

Re: Detect more keyboard cases when starting X

[Sevan Janiyan]

Hi Anthony,

On 26/12/2015 00:55, Anthony J. Bentley wrote:

As X starts, it will attempt to detect features from the kbd(8)
setting--for example, us.dvorak will enable dvorak in X, and
fr.dvorak will enable French dvorak in X. However, it detects
these features with equality checks, which will fail if multiple
options are set, as in the case of us.dvorak.swapctrlcaps or
fr.dvorak.swapctrlcaps.

Instead of checking for equality, this diff instead checks if the
bits are set. Now us.dvorak.swapctrlcaps and fr.dvorak.swapctrlcaps
work, us.swapctrlcaps.iopener swaps ctrl/caps, and the ones that
already worked (de.nodead, etc) still do.

This was reported on misc@ by "Sevan / Venture37" back in June.


Thanks for looking into it, I'm checking out the Xenocara consolidation 
as I type this. Will test & report back :)



Sevan

Re: Detect more keyboard cases when starting X

[Alexandr Shadchin]

On Fri, Dec 25, 2015 at 05:55:22PM -0700, Anthony J. Bentley wrote:
> Hi,
> 
> As X starts, it will attempt to detect features from the kbd(8)
> setting--for example, us.dvorak will enable dvorak in X, and
> fr.dvorak will enable French dvorak in X. However, it detects
> these features with equality checks, which will fail if multiple
> options are set, as in the case of us.dvorak.swapctrlcaps or
> fr.dvorak.swapctrlcaps.
> 
> Instead of checking for equality, this diff instead checks if the
> bits are set. Now us.dvorak.swapctrlcaps and fr.dvorak.swapctrlcaps
> work, us.swapctrlcaps.iopener swaps ctrl/caps, and the ones that
> already worked (de.nodead, etc) still do.
> 
> This was reported on misc@ by "Sevan / Venture37" back in June.
> 
> ok?
> 

ok shadchin@

> Index: config/wscons.c
> ===
> RCS file: /cvs/xenocara/xserver/config/wscons.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 wscons.c
> --- config/wscons.c   15 Jan 2015 01:30:40 -  1.14
> +++ config/wscons.c   25 Dec 2015 21:37:21 -
> @@ -139,7 +139,7 @@ wscons_add_keyboard(void)
>  break;
>  }
>  for (i = 0; kbdvar[i].val; i++)
> -if (wsenc == kbdvar[i].val || KB_VARIANT(wsenc) == kbdvar[i].val) {
> +if ((wsenc & kbdvar[i].val) == kbdvar[i].val) {
>  LogMessageVerb(X_INFO, 3, "wskbd: using variant %s\n",
> kbdvar[i].name);
>  input_options = input_option_new(input_options,
> @@ -147,7 +147,7 @@ wscons_add_keyboard(void)
>  break;
>  }
>  for (i = 0; kbdopt[i].val; i++)
> -if (KB_VARIANT(wsenc) == kbdopt[i].val) {
> +if (KB_VARIANT(wsenc) & kbdopt[i].val) {
>  LogMessageVerb(X_INFO, 3, "wskbd: using option %s\n",
> kbdopt[i].name);
>  input_options = input_option_new(input_options,
> 

-- 
Alexandr Shadchin

remove #ifndef MKNOD from ksh(1) and enforce pledge(2) on all codepaths

[Ricardo Mestre]

Hi tech@

Now that dpath annotation in pledge(2) is available then #ifndef MKNOD can be
removed and enforce pledge(2) on all codepaths, is this correct, comments?

Index: main.c
===
RCS file: /cvs/src/bin/ksh/main.c,v
retrieving revision 1.75
diff -u -p -u -r1.75 main.c
--- main.c  14 Dec 2015 13:59:42 -  1.75
+++ main.c  26 Dec 2015 18:23:34 -
@@ -154,13 +154,11 @@ main(int argc, char *argv[])
 
kshname = argv[0];
 
-#ifndef MKNOD
-   if (pledge("stdio rpath wpath cpath fattr flock getpw proc exec tty",
+   if (pledge("stdio rpath wpath cpath dpath fattr flock getpw proc exec 
tty",
NULL) == -1) {
perror("pledge");
exit(1);
}
-#endif
 
ainit();  /* initialize permanent Area */
 

Re: remove #ifndef MKNOD from ksh(1) and enforce pledge(2) on all codepaths

[Ricardo Mestre]

Or even better keep the #ifndef since mknod(8) already has dpath annotation:

Index: main.c
===
RCS file: /cvs/src/bin/ksh/main.c,v
retrieving revision 1.75
diff -u -p -u -r1.75 main.c
--- main.c  14 Dec 2015 13:59:42 -  1.75
+++ main.c  26 Dec 2015 18:31:45 -
@@ -160,6 +160,12 @@ main(int argc, char *argv[])
perror("pledge");
exit(1);
}
+#else
+   if (pledge("stdio rpath wpath cpath dpath fattr flock getpw proc exec 
tty",
+   NULL) == -1) {
+   perror("pledge");
+   exit(1);
+   }
 #endif

On 18:28 Sat 26 Dec , Ricardo Mestre wrote:
> Hi tech@
> 
> Now that dpath annotation in pledge(2) is available then #ifndef MKNOD can be
> removed and enforce pledge(2) on all codepaths, is this correct, comments?
> 
> Index: main.c
> ===
> RCS file: /cvs/src/bin/ksh/main.c,v
> retrieving revision 1.75
> diff -u -p -u -r1.75 main.c
> --- main.c  14 Dec 2015 13:59:42 -  1.75
> +++ main.c  26 Dec 2015 18:23:34 -
> @@ -154,13 +154,11 @@ main(int argc, char *argv[])
>  
> kshname = argv[0];
>  
> -#ifndef MKNOD
> -   if (pledge("stdio rpath wpath cpath fattr flock getpw proc exec tty",
> +   if (pledge("stdio rpath wpath cpath dpath fattr flock getpw proc exec 
> tty",
> NULL) == -1) {
> perror("pledge");
> exit(1);
> }
> -#endif
>  
> ainit();  /* initialize permanent Area */
>  

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

[Michael McConville]

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 -r1.268 faq8.html
> --- faq8.html 24 Nov 2015 00:20:25 -  1.268
> +++ faq8.html 26 Dec 2015 09:13:00 -
> @@ -316,6 +316,14 @@ This new compiler is available as a subp
>  
>  
>  
> +Go
> +
> +http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/go;>lang/go
> +
> +
> +
> +
> +
>  Haskell
>  
>   href="http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc;>lang/ghc
> @@ -430,6 +438,14 @@ Plenty of subpackages are available for 
>  Ruby
>  
>   href="http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/ruby;>lang/ruby
> +
> +
> +
> +
> +
> +Rust
> +
> + href="http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/rust;>lang/rust
>  
>  
>  
> 
> -- 
> Michal Mazurek
> 

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

[Michal Mazurek]

Go and Rust are now widely used. It might be worth mentioning them in
the FAQ.

Index: faq8.html
===
RCS file: /cvs/www/faq/faq8.html,v
retrieving revision 1.268
diff -u -p -r1.268 faq8.html
--- faq8.html   24 Nov 2015 00:20:25 -  1.268
+++ faq8.html   26 Dec 2015 09:13:00 -
@@ -316,6 +316,14 @@ This new compiler is available as a subp
 
 
 
+Go
+
+http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/go;>lang/go
+
+
+
+
+
 Haskell
 
 http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc;>lang/ghc
@@ -430,6 +438,14 @@ Plenty of subpackages are available for 
 Ruby
 
 http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/ruby;>lang/ruby
+
+
+
+
+
+Rust
+
+http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/rust;>lang/rust
 
 
 

-- 
Michal Mazurek

Re: utf8 input in el_gets(3)

[Dmitrij D. Czarkoff]

Christian Heckendorf said:
> > I remember someone recently mentioning that libedit is due for an
> > update. Maybe we should try to include this in a full sync.
> 
> Assuming someone isn't already working on it, I volunteer.

I work on it, and I sit on a huge diff for some time.  I'll send it out
once remaining issues are gone.

-- 
Dmitrij D. Czarkoff

Clarify factor(6)

[Michal Mazurek]

Index: factor.6
===
RCS file: /cvs/src/games/factor/factor.6,v
retrieving revision 1.12
diff -u -p -r1.12 factor.6
--- factor.624 Jan 2011 00:42:44 -  1.12
+++ factor.626 Dec 2015 08:56:37 -
@@ -58,7 +58,7 @@ When a number is factored, it is printed
 and the list of factors on a single line.
 Factors are listed in ascending order, and are preceded by a space.
 If a factor divides a value more than once, it will be printed
-more than once.
+that number of times.
 .Pp
 When
 .Nm

-- 
Michal Mazurek

Zlib regression tests

[Timo Myyrä]

Hi, 

I was bored a bit and noticed the latest zlib version contains tests in
example.c. I've cleaned up the file and added it to regress framework.
The testsuite shouldn't output anything if all is well.
I've changed the types quite a bit so someone with better understanding of C and
Zlib should review them so that they don't contain any suprises.

Timo

Index: regress/lib/Makefile
===
RCS file: /cvs/src/regress/lib/Makefile,v
retrieving revision 1.18
diff -u -u -p -r1.18 Makefile
--- regress/lib/Makefile31 Oct 2014 14:10:55 -  1.18
+++ regress/lib/Makefile26 Dec 2015 08:58:54 -
@@ -1,7 +1,7 @@
 #  $OpenBSD: Makefile,v 1.18 2014/10/31 14:10:55 jsing Exp $
 
 SUBDIR+= csu libc libcrypto libevent libm libpthread libskey libssl libtls \
-libutil
+libutil libz
 
 install:
 
Index: regress/lib/libz/Makefile
===
RCS file: regress/lib/libz/Makefile
diff -N regress/lib/libz/Makefile
--- /dev/null   1 Jan 1970 00:00:00 -
+++ regress/lib/libz/Makefile   26 Dec 2015 08:58:54 -
@@ -0,0 +1,6 @@
+PROG=zlib_testsuite
+LDADD=-lz
+
+CLEANFILES=foo.gz zlib_testsuite.o zlib_testsuite
+
+.include 
Index: regress/lib/libz/zlib_testsuite.c
===
RCS file: regress/lib/libz/zlib_testsuite.c
diff -N regress/lib/libz/zlib_testsuite.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ regress/lib/libz/zlib_testsuite.c   26 Dec 2015 08:58:54 -
@@ -0,0 +1,542 @@
+/*
+ * zlib_testsuite.c -- regression tests for zlib compression library
+ *
+ * Copyright (C) 1995-2006, 2011 Jean-loup Gailly.
+ * Copyright (C) 2015 Timo Myyrä.
+ *
+ * based on the example.c from upstream zlib distribution but modified for
+ * better fit for regression tests.
+ *
+ * For conditions of distribution and use, see copyright notice in zlib.h
+ */
+
+/* $OpenBSD$ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define CHECK_ERR(err, msg) { \
+if (err != Z_OK) { \
+fprintf(stderr, "%s error: %d\n", msg, err); \
+exit(1); \
+} \
+}
+
+const char hello[] = "hello, hello!";
+/*
+ * "hello world" would be more standard, but the repeated "hello" stresses
+ * the compression code better, sorry...
+ */
+
+const char dictionary[] = "hello";
+unsigned long  dictId; /* Adler32 value of the dictionary */
+
+void   test_compress(void *, size_t, void *, size_t);
+void   test_deflate(void *, size_t);
+void   test_deflate_levels(void);
+void   test_dict_deflate(void *, size_t);
+void   test_dict_inflate(void *, size_t, void *, size_t);
+void   test_flush(void *, size_t);
+void   test_gzio(const char *, void *, size_t);
+void   test_inflate(void *, size_t, void *, size_t);
+void   test_large_deflate(void *, size_t, void *, size_t);
+void   test_large_inflate(void *, size_t, void *, size_t);
+void   test_sync(void *, size_t, void *, size_t);
+
+/*
+ * Test compress() and uncompress()
+ */
+void
+test_compress(void *compr, size_t comprLen, void *uncompr, size_t uncomprLen)
+{
+   int err;
+   size_t  len = strlen(hello) + 1;
+
+   err = compress(compr, , (const unsigned char *)hello, len);
+   CHECK_ERR(err, "compress");
+
+   strlcpy((char *)uncompr, "garbage", sizeof(uncompr));
+
+   err = uncompress(uncompr, , compr, comprLen);
+   CHECK_ERR(err, "uncompress");
+
+   if (strcmp((char *)uncompr, hello) != 0) {
+   fprintf(stderr, "bad uncompress\n");
+   exit(1);
+   }
+}
+
+/*
+ * Test deflate() with small buffers
+ */
+void
+test_deflate(void *compr, size_t comprLen)
+{
+   z_streamc_stream;
+   int err;
+   size_t  len = strlen(hello) + 1;
+
+   c_stream.zalloc = NULL;
+   c_stream.zfree = NULL;
+   c_stream.opaque = NULL;
+
+   err = deflateInit(_stream, Z_DEFAULT_COMPRESSION);
+   CHECK_ERR(err, "deflateInit");
+
+   c_stream.next_in = (unsigned char *)hello;
+   c_stream.next_out = compr;
+
+   while (c_stream.total_in != (off_t)len && c_stream.total_out < 
(off_t)comprLen) {
+   /* force small buffers */
+c_stream.avail_in = c_stream.avail_out = 1;
+   err = deflate(_stream, Z_NO_FLUSH);
+   CHECK_ERR(err, "deflate");
+   }
+   /* Finish the stream, still forcing small buffers: */
+   for (;;) {
+   c_stream.avail_out = 1;
+   err = deflate(_stream, Z_FINISH);
+   if (err == Z_STREAM_END)
+   break;
+   CHECK_ERR(err, "deflate");
+   }
+
+   err = deflateEnd(_stream);
+   CHECK_ERR(err, "deflateEnd");
+}
+
+void
+test_deflate_levels(void)
+{
+   z_streamstrm;
+   int err, i;
+
+   strm.zalloc = NULL;
+   strm.zfree = NULL;
+   strm.opaque = NULL;
+
+   for (i = 0; i < 

Re: Detect more keyboard cases when starting X

[Sevan Janiyan]

On 26/12/2015 17:37, Sevan Janiyan wrote:
> Hi Anthony,
> 
> On 26/12/2015 00:55, Anthony J. Bentley wrote:
>> As X starts, it will attempt to detect features from the kbd(8)
>> setting--for example, us.dvorak will enable dvorak in X, and
>> fr.dvorak will enable French dvorak in X. However, it detects
>> these features with equality checks, which will fail if multiple
>> options are set, as in the case of us.dvorak.swapctrlcaps or
>> fr.dvorak.swapctrlcaps.
>>
>> Instead of checking for equality, this diff instead checks if the
>> bits are set. Now us.dvorak.swapctrlcaps and fr.dvorak.swapctrlcaps
>> work, us.swapctrlcaps.iopener swaps ctrl/caps, and the ones that
>> already worked (de.nodead, etc) still do.
>>
>> This was reported on misc@ by "Sevan / Venture37" back in June.
> 
> Thanks for looking into it, I'm checking out the Xenocara consolidation
> as I type this. Will test & report back :)

I checkout xenocara to my home directory on OpenBSD/i386 December 3rd
-current snapshot.
Made the changes in your patch.
As per xenocara/README I ran make bootstrap, obj and build.
The build process, fails with

===> data/xkeyboard-config/rules/compat
touch parts_done
HDR="/home/sme/xenocara/data/xkeyboard-config/rules/../../../dist/xkeyboard-config/rules/HDR"
/bin/sh
/home/sme/xenocara/data/xkeyboard-config/rules/../../../dist/xkeyboard-config/rules/merge.sh
base base.hdr.part base.lists.part  base.lists.base.part
compat/base.lists.part  HDR base.m_k.part  HDR base.l1_k.part  HDR
base.l_k.part  HDR base.o_k.part  HDR base.ml_g.part  HDR base.m_g.part
 HDR compat/base.mlv_s.partbase.mlv_s.part  HDR
compat/base.ml_s.part base.ml_s.part   HDR compat/base.ml1_s.part
 base.ml1_s.part  HDR compat/base.ml1v1_s.part  HDR
compat/base.ml2_s.partbase.ml2_s.part  HDR compat/base.ml3_s.part
 base.ml3_s.part  HDR compat/base.ml4_s.partbase.ml4_s.part  HDR
compat/base.ml2v2_s.part  HDR compat/base.ml3v3_s.part  HDR
compat/base.ml4v4_s.part  HDR base.m_s.part  HDR base.ml_s1.part  HDR
compat/base.lv_c.partHDR compat/base.l1v1_c.part  HDR
compat/base.l2v2_c.part  HDR compat/base.l3v3_c.part  HDR
compat/base.l4v4_c.part  HDR base.ml_c.part  HDR base.ml1_c.part  HDR
base.m_t.part  HDR base.lo_s.part  HDR base.l1o_s.part  HDR
base.l2o_s.part  HDR base.l3o_s.part  HDR base.l4o_s.part  HDR
compat/base.o_s.part base.o_s.part  HDR base.o_c.part  HDR base.o_t.part
cat:
/home/sme/xenocara/data/xkeyboard-config/rules/../../../dist/xkeyboard-config/rules/compat/base.mlv_s.part:
No such file or directory
*** Error 1 in data/xkeyboard-config/rules (Makefile:99 'base')
*** Error 1 in data/xkeyboard-config (:48 'all')
*** Error 1 in data/xkeyboard-config
(/usr/X11R6/share/mk/bsd.xorg.mk:211 'build')
*** Error 1 in data (:48 'build')
*** Error 1 in . (:48 'realbuild')
*** Error 1 in /home/sme/xenocara (Makefile:41 'build')

I haven't ruled out PEBKAC, this is the first time I've attempted to
build xenocara I believe.


Sevan

Re: Clarify factor(6)

[Theo Buehler]

On Sat, Dec 26, 2015 at 09:57:57PM +, Jason McIntyre wrote:
> On Sat, Dec 26, 2015 at 10:01:34AM +0100, Michal Mazurek wrote:
> > Index: factor.6
> > ===
> > RCS file: /cvs/src/games/factor/factor.6,v
> > retrieving revision 1.12
> > diff -u -p -r1.12 factor.6
> > --- factor.624 Jan 2011 00:42:44 -  1.12
> > +++ factor.626 Dec 2015 08:56:37 -
> > @@ -58,7 +58,7 @@ When a number is factored, it is printed
> >  and the list of factors on a single line.
> >  Factors are listed in ascending order, and are preceded by a space.
> >  If a factor divides a value more than once, it will be printed
> > -more than once.
> > +that number of times.
> >  .Pp
> >  When
> >  .Nm
> > 
> 
> i am not the right guy to take this but i want to point out that
> the source code has virtually the same comment as the man page, so
> if someone agrees the man page needs changed they might want to
> bump the source code too.

Yes, the current phrasing is a bit vague.  I'm not convinced the
suggestion is better, since it still leaves the number of times a
factor is printed undefined.  How about:

Index: factor.6
===
RCS file: /var/cvs/src/games/factor/factor.6,v
retrieving revision 1.12
diff -u -p -r1.12 factor.6
--- factor.624 Jan 2011 00:42:44 -  1.12
+++ factor.626 Dec 2015 22:04:54 -
@@ -57,8 +57,7 @@ When a number is factored, it is printed
 .Sq \&: ,
 and the list of factors on a single line.
 Factors are listed in ascending order, and are preceded by a space.
-If a factor divides a value more than once, it will be printed
-more than once.
+Every factor is printed as often as it divides the number.
 .Pp
 When
 .Nm

iwn timeouts

[Michael McConville]

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 master

This happens on both ramdisks and installed kernels. After I run
netstart again, it works until the next boot.

/etc/hostname.iwn0 is just:

> nwid mynet
> wpakey mypasswd
> 
> dhcp
> rtsol

I'm pretty sure it happens without rtsol, as I've gone without it in the
past. I'll test this on my next reboot.

I've shelved this in the past because those I've talked to with
identical laptops and cards don't have this problem. However, Theo
thinks it's likely a driver bug, so I decided to bring it up.

Thoughts? Additional info needed? I'm happy to run debug builds if it'd
help.



OpenBSD 5.9-beta (GENERIC.MP) #1778: Wed Dec 23 18:23:06 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4062691328 (3874MB)
avail mem = 3935440896 (3753MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
bios0: vendor LENOVO version "6QET61WW (1.31 )" date 10/26/2010
bios0: LENOVO 3626FAU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA SSDT 
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) 
EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.55 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.00 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.00 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 13 (EXP1)
acpiprt3 at acpi0: bus -1 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus 5 (EXP4)
acpiprt6 at acpi0: bus 2 (EXP5)
acpicpu0 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpicpu1 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpicpu2 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpicpu3 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T4694" serial  1408 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 2793 MHz: speeds: 2534, 2533, 2399, 2266, 2133, 1999, 
1866, 1733, 1599, 1466, 1333, 1199 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x02
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x02
drm0 at 

Re: Clarify factor(6)

[Jason McIntyre]

On Sat, Dec 26, 2015 at 10:01:34AM +0100, Michal Mazurek wrote:
> Index: factor.6
> ===
> RCS file: /cvs/src/games/factor/factor.6,v
> retrieving revision 1.12
> diff -u -p -r1.12 factor.6
> --- factor.6  24 Jan 2011 00:42:44 -  1.12
> +++ factor.6  26 Dec 2015 08:56:37 -
> @@ -58,7 +58,7 @@ When a number is factored, it is printed
>  and the list of factors on a single line.
>  Factors are listed in ascending order, and are preceded by a space.
>  If a factor divides a value more than once, it will be printed
> -more than once.
> +that number of times.
>  .Pp
>  When
>  .Nm
> 

i am not the right guy to take this but i want to point out that
the source code has virtually the same comment as the man page, so
if someone agrees the man page needs changed they might want to
bump the source code too.

jmc

Re: bug in fputwc(3) error reporting

[Jérémie Courrèges-Anglas]

Ingo Schwarze  writes:

[...]

> When fputwc(3) encounters an encoding error, it neglects to set the
> error indicator, just like fgetwc(3) did before i fixed it today.
> Setting the error indicator is required by the manual and by the
> standard.

Hmm, the C standard and POSIX have slightly different texts regarding
this.

Quoting POSIX-2013:
-->8--
  RETURN VALUE

Upon successful completion, fputwc() shall return wc. Otherwise, it
shall return WEOF, the error indicator for the stream shall be set,
[CX] and errno shall be set to indicate the error.
--<8--

Quoting the C99 draft, section 7.24.3.3:
--8<--
Returns

3 The fputwc function returns the wide character written. If a write
error occurs, the error indicator for the stream is set and fputwc
returns WEOF. If an encoding error occurs, the value of the macro EILSEQ
is stored in errno and fputwc returns WEOF.
-->8--

Note that the C11 draft has the same text.

So, the C standard doesn't say that the error indicator should be set on
the FILE in case of an encoding error, it only speaks about errno being
set to EILSEQ.  I'd say that we should follow the C standard here -
after all "This volume of POSIX.1-2008 defers to the ISO C standard".

The same can be said about the fgetwc(3) diff that was recently
committed, and for which I gave you an ok.

> Instead, it overrides errno again.  That's pointless because
> wcrtomb(3) already did that, and is required to do so by the standard.
> It is even slightly dangerous because it might hide internal coding
> errors in libc.  For example, if libc would ever neglect to initialize
> the state object correctly, wcrtomb(3) might fail with EINVAL.
> That should NOT be plastered over by setting errno to EILSEQ.

I agree that errno doesn't need to be overriden, but please leave _flags
alone.

[...]

> Index: fputwc.c
> ===
> RCS file: /cvs/src/lib/libc/stdio/fputwc.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 fputwc.c
> --- fputwc.c  1 Oct 2015 02:32:07 -   1.6
> +++ fputwc.c  24 Dec 2015 21:01:10 -
> @@ -62,7 +62,7 @@ __fputwc_unlock(wchar_t wc, FILE *fp)
>  
>   size = wcrtomb(buf, wc, st);
>   if (size == (size_t)-1) {
> - errno = EILSEQ;
> + fp->_flags |= __SERR;
>   return WEOF;
>   }
>  


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: Clarify factor(6)

[Theo Buehler]

On Sat, Dec 26, 2015 at 11:09:35PM +0100, Theo Buehler wrote:
> On Sat, Dec 26, 2015 at 09:57:57PM +, Jason McIntyre wrote:
> > On Sat, Dec 26, 2015 at 10:01:34AM +0100, Michal Mazurek wrote:
> > > Index: factor.6
> > > ===
> > > RCS file: /cvs/src/games/factor/factor.6,v
> > > retrieving revision 1.12
> > > diff -u -p -r1.12 factor.6
> > > --- factor.6  24 Jan 2011 00:42:44 -  1.12
> > > +++ factor.6  26 Dec 2015 08:56:37 -
> > > @@ -58,7 +58,7 @@ When a number is factored, it is printed
> > >  and the list of factors on a single line.
> > >  Factors are listed in ascending order, and are preceded by a space.
> > >  If a factor divides a value more than once, it will be printed
> > > -more than once.
> > > +that number of times.
> > >  .Pp
> > >  When
> > >  .Nm
> > > 
> > 
> > i am not the right guy to take this but i want to point out that
> > the source code has virtually the same comment as the man page, so
> > if someone agrees the man page needs changed they might want to
> > bump the source code too.

Maybe we should just go all the way:

o 'factor' is synonymous with 'divisor', so we should really say
  'prime factor', not only 'factor'.
o Incorporate my previous suggestion 'every prime factor is printed
  as often as it divides the number'.
o follow jmc@'s suggestion to update the comment in the source code
  as well

Index: factor.6
===
RCS file: /var/cvs/src/games/factor/factor.6,v
retrieving revision 1.12
diff -u -p -r1.12 factor.6
--- factor.624 Jan 2011 00:42:44 -  1.12
+++ factor.626 Dec 2015 22:34:55 -
@@ -55,10 +55,10 @@ The
 utility will factor 64-bit positive integers.
 When a number is factored, it is printed, followed by a
 .Sq \&: ,
-and the list of factors on a single line.
-Factors are listed in ascending order, and are preceded by a space.
-If a factor divides a value more than once, it will be printed
-more than once.
+and the list of its prime factors on a single line.
+The prime factors are listed in ascending order, and are
+preceded by a space.
+Every prime factor is printed as often as it divides the number.
 .Pp
 When
 .Nm
Index: factor.c
===
RCS file: /var/cvs/src/games/factor/factor.c,v
retrieving revision 1.23
diff -u -p -r1.23 factor.c
--- factor.c25 Dec 2015 20:59:09 -  1.23
+++ factor.c26 Dec 2015 22:22:35 -
@@ -143,17 +143,16 @@ main(int argc, char *argv[])
 }
 
 /*
- * pr_fact - print the factors of a number
+ * pr_fact - print the prime factors of a number
  *
  * If the number is 0 or 1, then print the number and return.
  * If the number is < 0, print -1, negate the number and continue
  * processing.
  *
  * Print the factors of the number, from the lowest to the highest.
- * A factor will be printed multiple times if it divides the value
- * multiple times.
+ * A prime factor will be printed as often as it divides the value.
  *
- * Factors are printed with leading tabs.
+ * Prime factors are printed with leading spaces.
  */
 void
 pr_fact(u_int64_t val) /* Factor this value. */

Re: bugs in printf(3)

[Jérémie Courrèges-Anglas]

Ingo Schwarze  writes:

> Fourth file, fourth broken file.
> This is the worst bug found so far.
> All i'm doing is grepping libc/stdio for "EILSEQ".
> So far, every single instance i looked at was buggy.
>
> I think we should cvs rm libc.
> The code quality just isn't up to OpwnBSD standards.
>
>
> When fprintf(fp, "...%ls...", ...) encounters an encoding error,
> it trashes fp BEYOND REPAIR, clearing all FILE flags, making the
> file unreadable, unwriteable, and probably breaking even more than
> that.  Calling clearerr(3) is by far insufficient to undo the
> devastating damage done.
>
> Besides, i don't see the point in messing with FILE flags at all
> in case of encoding errors.  As opposed to fgetwc(3) and fputwc(3),
> the manual doesn't document this fiddling, and POSIX doesn't ask
> for it.  No other conversions in printf(3) set the error indicator.
> It isn't required because printf(3) provides a proper error return
> (-1) in the first place.  Has anybody ever seen any code calling
> ferror(3) after printf(3)?  That just wouldn't make sense.
> Of course, printf(3) can result in the error indicator getting set,
> but only if the underlying low-level write calls fail.
>
> So, don't fp->_flags = __SERR; (sic, no |= here!),
> don't even fp->_flags |= __SERR;.
>
> While here, as usual, remove the pointless and slightly dangerous
> errno = EILSEQ overrides after functions that already do that
> and are required by the standard to do so.

[...]

> Note that all code changes below are in parts guarded with
> #ifdef PRINTF_WIDE_CHAR
> so there is no risk of breaking printf(3) at large.
>
> OK?

Makes sense to me, ok jca@

(I'll review your next diff later.)

>   Ingo
>
>
> Index: stdio/vfprintf.c
> ===
> RCS file: /cvs/src/lib/libc/stdio/vfprintf.c,v
> retrieving revision 1.69
> diff -u -p -r1.69 vfprintf.c
> --- stdio/vfprintf.c  29 Sep 2015 03:19:24 -  1.69
> +++ stdio/vfprintf.c  24 Dec 2015 22:58:33 -
> @@ -165,10 +165,8 @@ __wcsconv(wchar_t *wcsarg, int prec)
>   memset(, 0, sizeof(mbs));
>   p = wcsarg;
>   nbytes = wcsrtombs(NULL, (const wchar_t **), 0, );
> - if (nbytes == (size_t)-1) {
> - errno = EILSEQ;
> + if (nbytes == (size_t)-1)
>   return (NULL);
> - }
>   } else {
>   /*
>* Optimisation: if the output precision is small enough,
> @@ -188,10 +186,8 @@ __wcsconv(wchar_t *wcsarg, int prec)
>   break;
>   nbytes += clen;
>   }
> - if (clen == (size_t)-1) {
> - errno = EILSEQ;
> + if (clen == (size_t)-1)
>   return (NULL);
> - }
>   }
>   }
>   if ((convbuf = malloc(nbytes + 1)) == NULL)
> @@ -203,7 +199,6 @@ __wcsconv(wchar_t *wcsarg, int prec)
>   if ((nbytes = wcsrtombs(convbuf, (const wchar_t **),
>   nbytes, )) == (size_t)-1) {
>   free(convbuf);
> - errno = EILSEQ;
>   return (NULL);
>   }
>   convbuf[nbytes] = '\0';
> @@ -640,8 +635,7 @@ reswitch: switch (ch) {
>   mbseqlen = wcrtomb(buf,
>   (wchar_t)GETARG(wint_t), );
>   if (mbseqlen == (size_t)-1) {
> - fp->_flags |= __SERR;
> - errno = EILSEQ;
> + ret = -1;
>   goto error;
>   }
>   cp = buf;
> @@ -855,7 +849,7 @@ fp_common:
>   } else {
>   convbuf = __wcsconv(wcp, prec);
>   if (convbuf == NULL) {
> - fp->_flags = __SERR;
> + ret = -1;
>   goto error;
>   }
>   cp = convbuf;
>

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: bug in fputwc(3) error reporting

[Anthony J. Bentley]

Hi Jérémie,

Jérémie Courrèges-Anglas writes:
> Hmm, the C standard and POSIX have slightly different texts regarding
> this.
> 
> Quoting POSIX-2013:
> -->8--
>   RETURN VALUE
> 
> Upon successful completion, fputwc() shall return wc. Otherwise, it
> shall return WEOF, the error indicator for the stream shall be set,
> [CX] and errno shall be set to indicate the error.
...
> So, the C standard doesn't say that the error indicator should be set on
> the FILE in case of an encoding error, it only speaks about errno being
> set to EILSEQ.  I'd say that we should follow the C standard here -
> after all "This volume of POSIX.1-2008 defers to the ISO C standard".

The [CX] there means it's an intentional extension of ISO C. This is
more obvious in the HTML copy of POSIX,
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fputwc.html

Quoting more POSIX (the [CX] defintion),

The functionality described is an extension to the ISO C standard.
Application developers may make use of an extension as it is
supported on all POSIX.1-2008-conforming systems.

With each function or header from the ISO C standard, a statement to
the effect that "any conflict is unintentional" is included. That is
intended to refer to a direct conflict. POSIX.1-2008 acts in part as
a profile of the ISO C standard, and it may choose to further
constrain behaviors allowed to vary by the ISO C standard.

-- 
Anthony J. Bentley

Re: bug in fputwc(3) error reporting

[Jérémie Courrèges-Anglas]

"Anthony J. Bentley"  writes:

> Hi Jérémie,

Hi,

> Jérémie Courrèges-Anglas writes:
>> Hmm, the C standard and POSIX have slightly different texts regarding
>> this.
>> 
>> Quoting POSIX-2013:
>> -->8--
>>   RETURN VALUE
>> 
>> Upon successful completion, fputwc() shall return wc. Otherwise, it
>> shall return WEOF, the error indicator for the stream shall be set,
>> [CX] and errno shall be set to indicate the error.
> ...
>> So, the C standard doesn't say that the error indicator should be set on
>> the FILE in case of an encoding error, it only speaks about errno being
>> set to EILSEQ.  I'd say that we should follow the C standard here -
>> after all "This volume of POSIX.1-2008 defers to the ISO C standard".
>
> The [CX] there means it's an intentional extension of ISO C.

The way I read it, [CX] here only affects the last part of the sentence,

  "and errno shall be set to indicate the error."

(because the C standard doesn't require errno to be set in all error
cases.)

Thus [CX] here doesn't apply to the part that speaks about the error
indicator.

> This is
> more obvious in the HTML copy of POSIX,
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fputwc.html
>
> Quoting more POSIX (the [CX] defintion),
>
> The functionality described is an extension to the ISO C standard.
> Application developers may make use of an extension as it is
> supported on all POSIX.1-2008-conforming systems.
>
> With each function or header from the ISO C standard, a statement to
> the effect that "any conflict is unintentional" is included. That is
> intended to refer to a direct conflict. POSIX.1-2008 acts in part as
> a profile of the ISO C standard, and it may choose to further
> constrain behaviors allowed to vary by the ISO C standard.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE