Mike Frysinger a277af22ea split assume pipe2/dup3/sock_cloexec knobs ... We can't assume sock_cloexec and pipe2 are bound together as the former defines are found in glibc only while the latter are a combo of kernel headers and glibc. So if we do a runtime detection of SOCK_CLOEXEC, but pipe2() is a stub inside of glibc, we hit a problem. For example: main() { getgrnam("portage"); if (!popen("ls", "r")) perror("popen()"); } getgrnam() will detect that the kernel supports SOCK_CLOEXEC and then set both __have_sock_cloexec and __have_pipe2 to true. But if glibc was built against older kernel headers where __NR_pipe2 does not exist, glibc will have a ENOSYS stub for it. So popen() will always fail as glibc assumes pipe2() works. While this isn't too much of an issue for some arches as they added the functionality to the kernel at the same time, not all arches are that lucky. Since the code already has dedicated names for each feature, delete the defines wiring these three features together and make each one a proper dedicated knob. We've been carrying this in Gentoo since glibc-2.9. Signed-off-by: Mike Frysinger <vapier@gentoo.org>		2012-08-18 00:35:47 -04:00
..
bits
sys
accept4.c
accept.c
bind.c
connect.c
getpeername.c
getsockname.c
getsockopt.c
have_sock_cloexec.c	split assume pipe2/dup3/sock_cloexec knobs	2012-08-18 00:35:47 -04:00
isfdtype.c
listen.c
Makefile
opensock.c
recv.c
recvfrom.c
recvmsg.c
send.c
sendmsg.c
sendto.c
setsockopt.c
shutdown.c
sockatmark.c
socket.c
socketpair.c
Versions