Revert "RHEL 5: Define O_CLOEXEC and SOCK_CLOEXEC."
This reverts commit
25206df20275aeff346d9b86adf5e9be99cc9e43, and
temporarily breaks compilation on Haiku which has O_CLOEXEC but lacks
SOCK_CLOEXEC [1].
An upcoming patch wants to ensure no leaked fds from the server to a
child process. POSIX has required O_CLOEXEC since 2008, and that is
long enough that we should start blindly relying on it. Meanwhile,
POSIX doesn't yet specify full atomic interfaces everywhere
(SOCK_CLOEXEC and accept4 when dealing with sockets, pipe2 when
dealing with pipes, mkostemp and fopen("re") when dealing with stdio,
etc.), but there has been an open bug since 2014 [2] recommending the
full set of interfaces that will be mandatory in the next revision of
POSIX. Most modern OS have caught up to that (RHEL 6 and FreeBSD 10
support SOCK_CLOEXEC, for example), and we're doing ourselves a
disservice by using a globally-silent and leaky fallback instead of
actively documenting at each site that prefers to use the new
interfaces whether the use is essential or merely reducing lines of
code, for the sake of systems that are behind in atomic support.
[1] https://dev.haiku-os.org/ticket/15219
[2] http://austingroupbugs.net/view.php?id=411
Conflicts:
filters/xz/xzfile.c - The fallback moved from plugins/xz/xzfile.c (and
in fact has been dead code since commit
c879d310 made it a filter)
plugins/file/file.c - context changes in the meantime
src/internal.h - Moved to server/internal.h
plugins/split/split.c - Not in the original patch; copied in
9ad64ba5