Exactly. As I said earlier, if you forget to clear FD_CLOEXEC when you meant to then your program breaks loudly and obviously; if you forget to *set* FD_CLOEXEC then the bug is much quieter and more subtle.
I asked for a specific example of some existing code that would be broken by this, but none was forthcoming. I understand why, in theory, changing this would be a problem (indeed, changing anything is similarly problematic) but in practice the pros enormously outweigh the cons here.
On 30/08/15 16:59, Donn Cave wrote:
> Quoth Niklas Hambüchen <mail@nh2.me>,
> ... and you go on to demonstrate that you didn't really take the point
> I was trying to make. How did you find out about this flock(2) scenario?
> Do you suppose that this is the only one, because you and I don't know
> of any more?
No, I do take your point, and I admit that more things may break when
changing the default.
What I'm saying is that such cases are relatively easy to find. When you
rely on inheriting FDs, you know it.
It is exotic enough that when you've built something that needs it,
you'll remember it.
This leads me to think that the damage done / cost to fix introduced by
breaking the backwards compatibility here might be smaller than the
damage / fixing that will arise in the future from surprising behaviour
and security/privilege problems through leaked FDs in all non-exotic
programs that want to exec() something. I'd assume the Python and Perl
people came to this conclusion.
Further, our community is small, and if you announce something loud and
long-term via mailing list and Reddit, it will go a long way and make it
unlikely that somebody will be unaware of such a change. Your point that
we may break things that we don't know of / understand still stands though.
Regarding pipes and sockets, pipe()/socket() accept CLOEXEC as well.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe