4 ms·
That kind of mitigation just makes me one step away from Rust - system programming languages should stick to the platform behavior, otherwise it's just another
by htfy96 8y ago
That kind of mitigation just makes me one step away from Rust - system programming languages should stick to the platform behavior, otherwise it's just another Python. Moreover this change is not documented anywhere else. Have a look at how GLib handle these cases[0]:
> - during the GSubprocess discussion, I originally held the opposite
opinion, but eventually became convinced (by Colin) to see the
inherit-by-default behaviour of exec() as nothing more than a
questionable implementation detail of the underlying OS. Consequently,
at the high level, GSubprocess provides an API that gives the caller
direct control over what is inherited and what is not, and that's just
the way that it should be.
> - this behaviour is not limited to GSubprocess. Closing all fds before
calling exec() is a common practice in modern libraries and runtimes,
and for good reason.
[0]: https://mail.gnome.org/archives/gtk-devel-list/2015-March/msg00038.html https://mail.gnome.org/archives/gtk-devel-list/2015-March/ms...
- pcwalton 8y ago> That kind of mitigation just makes me one step away from Rust - system programming languages should stick to the platform behavior, otherwise it's just another Python. That's silly. The standard library of new systems programming languages should do the safe thing, not inherit all the mistakes of the OS that the OS can't fix due to backwards compatibility. If Unix were being designed today, I am certain O_CLOEXEC would have been the default. Besides, Rust's behavior matches what happens on Windows, and cross-platform consistency in the standard library is desirable. In any case, what glib does matches what the Rust standard library does. The latter uses posix_spawn() directly in order to make sure no file descriptors are passed between parent and child. There is an API available to request file descriptor sharing explicitly.