Should std::os::pipe() be unsafe?

[steveklabnik]

The docs say:

This function is also unsafe as there is no destructor associated with the Pipe structure will return. If it is not arranged for the returned file descriptors to be closed, the file descriptors will leak.

However, resource leaks are explicitly behavior not considered unsafe.

Is this just a strange wording in pipe's docs, or is this overly unsafe?

[sfackler]

Seems overly unsafe to me.

[steveklabnik]

@alexcrichton you apparently wrote the signature of this function, or at least touched it last. Thoughts?

[alexcrichton]

Questions like this are largely addressed during API stabilization, and we haven't gotten to the std::os module (but we should soon!).

[l0kod]

However, resource leaks are explicitly behavior not considered unsafe.

The documentation only highlight the memory leak, not the other system resource leaks like file descriptor, which could have a more important impact (i.e. data confidentiality and integrity).

Possibility of file descriptor leak should be marked as unsafe.

Implementing an IoHandle<Fd> (i.e. generic FileDesc) could fix this ;-)

cc #19169
cc @aturon

[thestinger]

Creating and leaking a file descriptor doesn't qualify as unsafe. Rust allows leaking resources in safe code by creating a reference cycle with one of the many reference counted types (Rc, Arc, some forms of channels, etc.). It doesn't impact memory safety, and it's orthogonal to the issue of "leaking" file descriptors past exec boundaries. A file descriptor created without CLOEXEC will leak to processes spawned in any thread - it doesn't matter if Rust actually leaks it.

[aturon]

Possibility of file descriptor leak should be marked as unsafe.

In general, unsafe is meant to refer to only the core safety guarantees provided by Rust: memory safety, type safety, and data-race freedom. Other notions of safety (some of which you can enforce using the type system) are fine, but don't interact with the unsafe qualifier.

[aturon]

I'm going to close this for now, in favor of the stabilization process.