In man page cmsg(3), I see the following prose: "Finally, the msg_controllen field of the msghdr should be set to the sum of the CMSG_SPACE() of the length of all control messages in the buffer. For more information on the msghdr, see recvmsg(2)." Then, in the sample code at the bottom, I see this code: msg.msg_control = buf; msg.msg_controllen = sizeof buf; cmsg = CMSG_FIRSTHDR(&msg); cmsg->cmsg_level = SOL_SOCKET; cmsg->cmsg_type = SCM_RIGHTS; cmsg->cmsg_len = CMSG_LEN(sizeof(int) * NUM_FD); /* Initialize the payload: */ fdptr = (int *) CMSG_DATA(cmsg); memcpy(fdptr, myfds, NUM_FD * sizeof(int)); /* Sum of the length of all control messages in the buffer: */ msg.msg_controllen = cmsg->cmsg_len; This is inconsistent: the prose states that msg_controllen should be initialized with the sum of CMSG_SPACE across all messages, whereas the example code shows msg_controllen being initialized with cmsg->cmsg_len, which is itself initialized with CMSG_LEN, not CMSG_SPACE. I don't know what the right answer is, but for control messages whose length is not a multiple of the alignment requirement, this could make a difference. Reproducible: Always Steps to Reproduce:
Hi, this files is not altered by cardoe@g.o patch to upstream sources. Have you reported the issue upstream? https://bugzilla.kernel.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Documentation&component=man-pages&long_desc_type=substring&long_desc=&cf_kernel_version_type=allwordssubstr&cf_kernel_version=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=REJECTED&bug_status=DEFERRED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Doesn't list it.
No, this hasn't gone upstream. I didn't know where exactly upstream was for the man-pages package. Do you want me to report it, or will you?
Since i don't know the exact problem with the ebuilds, it would be better if you file the upstream bug and attach it's link to this bug (URL field). But i can provide you with informations about how to get informations about packages. -(if you have eix installed) `eix <package>` lists the homepage which should reveal a upstream bugtracker. Ok, this example is ab bit tricky the find the right package and not fall into the kernel attractor. You can also look at the SRC_URI entries of the ebuild ( vi `equery which <package>` ) or search for it in the mention /var/tmp/portage/<category>/<package full version>/temp/environment file. In this case you see the gentoo specific patch set beside the upstream sources. [Test if it's resolved in newer version] You can run "ebuild `ACCEPT_KEYWORDS=~* equery which man-pages` clean unpack" and investigate the situation in the latest in the .../work directory. You can replace unpack with install (this does not install to system /) and look at the .../image directory what this version would install. It's not that complicated to examine where the bits come from. "man 1 ebuild" and man 5 ebuild" is a good starting point, if you're willing to know how Gentoo is installing things. I don't know if there's a regular user compartible guide for things like that. http://devmanual.gentoo.org needs some time to get things together.
