Just a nitpick:
On 6 November 2013 01:41, Keith Packard kei...@keithp.com wrote:
Requests signal which replies will have fds, and the replies report
how many fds they expect in byte 1.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/c_client.py | 65
On Thu, Nov 7, 2013 at 15:11:30 +0100, Daniel Martin wrote:
Just a nitpick:
On 6 November 2013 01:41, Keith Packard kei...@keithp.com wrote:
Requests signal which replies will have fds, and the replies report
how many fds they expect in byte 1.
Signed-off-by: Keith Packard
Julien Cristau jcris...@debian.org writes:
better even without the []
Just proving that I can write C in any language.
--
keith.pack...@intel.com
pgpoJ3Waau85o.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives:
Date: Wed, 6 Nov 2013 12:14:21 -0500 (EST)
From: Mouse mo...@rodents-montreal.org
Same comment about not using the CMSG_ API properly.
Same comment about it being a broken API; I would say it's broken
enough that it's not possible to use it properly.
It's horrible, yes. And you're
Same comment about not using the CMSG_ API properly.
Same comment about it being a broken API; I would say it's broken
enough that it's not possible to use it properly.
It's horrible, yes. And you're right, CMSG_LEN/CMSG_SPACE was broken
on NetBSD for quite a while. But that was finally
From: Keith Packard kei...@keithp.com
Date: Tue, 5 Nov 2013 16:41:24 -0800
Requests signal which replies will have fds, and the replies report
how many fds they expect in byte 1.
Same comment about not using the CMSG_ API properly. Error handling
of the recvmsg(2) call isn't adequate
Same comment about not using the CMSG_ API properly.
Same comment about it being a broken API; I would say it's broken
enough that it's not possible to use it properly.
But my real point here is not to broken-record that, but to add a
remark which I neglected to mention when I wrote about
Mark Kettenis mark.kette...@xs4all.nl writes:
Same comment about not using the CMSG_ API properly. Error handling
of the recvmsg(2) call isn't adequate either. Probably should
consider MSG_TRUNC and MSG_CTRUNC as fatal errors and clean up any
file descriptors that you did receive like we
Requests signal which replies will have fds, and the replies report
how many fds they expect in byte 1.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/c_client.py | 65
src/xcb_in.c| 76
