Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RawOs marker traits #1256

Open
Stebalien opened this issue Aug 14, 2015 · 4 comments
Open

RawOs marker traits #1256

Stebalien opened this issue Aug 14, 2015 · 4 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@Stebalien
Copy link
Contributor

Currently, the {As,From}Raw{Fd,Handle} traits don't provide any information about how the file descriptors might safely be used (and don't even guarantee that the file descriptor is valid). Therefore, I would like to propose traits like:

/// Can safely write
unsafe trait RawOsWrite {}
/// Can safely read
unsafe trait RawOsRead {}
/// Can safely seek
unsafe trait RawOsSeek {}
/// Can safely access metadata. May not be necessary (always safe)?
unsafe trait RawOsMeta {}

These traits, when implemented on a type implementing one of the AsRaw/IntoRaw traits, would guarantee that the specified operation can be performed on the file descriptor/handle without causing memory unsafety. This doesn't mean that the operation will succeed, just that it won't be unsafe.

Unresolved: For AsRaw*, it's unclear when this guarantee expires. Personally, I'd like to say that the guarantee holds until the file descriptor owner is dropped but I don't know if that's reasonable.

@Diggsey
Copy link
Contributor

Diggsey commented Aug 15, 2015

I like this idea, but might not the guarantees be more subtle than these traits would be able to express? For example, safety might depend on certain runtime state, such as how the file was opened, whether a buffer has been flushed, or even whether the access is concurrent or not.

@Stebalien
Copy link
Contributor Author

For example, safety might depend on certain runtime state, such as how the file was opened, whether a buffer has been flushed, or even whether the access is concurrent or not.

That's why I said "memory safe" operations (or, more conservatively, operations that will not break type safety). How a file is opened is irrelevant because, if a file is opened read-only, writing to it will fail (but won't cause memory unsafety). A buffered reader/writer should probably only implement RawOsMeta, if anything.

@sfackler
Copy link
Member

What memory safety issues would arise from writing or reading directly to the underlying file descriptor inside of a buffered reader or writer?

@Stebalien
Copy link
Contributor Author

What memory safety issues would arise from writing or reading directly to the underlying file descriptor inside of a buffered reader or writer?

The problem isn't first-order bugs but second-order bugs. Type A fails to behave properly but isn't "memory unsafe". Type B uses type A in some unsafe code expecting it to conform to some specification and it doesn't leading to memory unsafety. That's why I prefer "operations that will not break type safety/guarantees" over "memory safety".

For example, I've been wanting to implement a more efficient IO copy function that uses sendfile. Out of order writes (due to buffering) to a trusted/private file could lead to memory unsafety on read.

@nrc nrc added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Aug 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

4 participants