Date: Sun, 3 May 2009 20:36:59 +0200 From: Marc Lehmann <[email protected]>
Hmm... this gets too complicated for my tastes. Do you think that getting rid of CMSG_SPACE and CMSG_LEN completely and just using a struct with the cmsg header and an int would be ultimately more portable? I don't think it would be. The field sizes and alignment requirements are up to the kernel, not to the C compiler, and exposed through the CMSG_SPACE and CMSG_LEN constructs. (The only reason malloc, or a stack-allocated union with a struct cmsghdr member, is necessary for alignment is that C programs must operate on the cmsghdr struct's fields, which must therefore be aligned, before passing the buffer to the kernel.) On NetBSD, the kernel's field size and alignment requirements are determined at run-time. I know the API is unpleasant, but it is what everyone will guarantee to work. Since both are just ipv6 extensions, I guess systems supporting fd passig must support using "old style" structs. And that would simplify fdpass.C even more. Only the CMSG_SPACE and CMSG_LEN macros are RFC 2252 extensions. The rest of the cmsghdr interface is in the SUSv3, whereas the old msg_accrights interface is not. Some operating systems support the old msc_accrights interface, but in some cases only for binary compatibility. In any case, I'm not aware of what Unix platforms don't have CMSG_SPACE and CMSG_LEN: NetBSD, OpenBSD, FreeBSD, Linux, and Solaris all do, for example. If you are willing to test, I could come up with such a change for fdpass.C. Otherwie, I'll just use your patch, which ahs the advantage of being verified to work :) Unfortunately, I can't test any other changes at the moment. (As you may observe from the dates on the patch, I procured it several months ago and promptly forgot to submit it; now the hardware on which I tested it is unavailable.) _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
