Skip to content

Conversation

@crumblingstatue
Copy link

Some APIs, like nonblock::NonBlockingReader::from_fd take a value that implements AsRawFd.

Pty implements AsRawFd, but if we pass it by value, it will get moved, as it doesn't implement Clone or Copy.

With this change, &Pty can now be passed without moving the Pty.

Some APIs, like `nonblock::NonBlockingReader::from_fd`
take a value that implements AsRawFd.

Pty implements AsRawFd, but if we pass it by value, it will
get moved, as it doesn't implement Clone or Copy.

With this change, &Pty can now be passed without moving the
Pty.
@doy
Copy link
Owner

doy commented Jul 8, 2025

this feels a bit odd - other things that implement AsRawFd don't do this, so it feels like it would make more sense to change this on the nonblock side? i'm open to arguments for why that shouldn't be the case, but forcing every crate to implement both versions seems weird to me.

@crumblingstatue
Copy link
Author

I can try opening a pull request on the nonblock repo later today, and see if there are any objections.

@crumblingstatue
Copy link
Author

Well, I tried to see if I can make a simple change on the nonblock-rs side, but I'm not sure what to do.
The way it works is by taking ownership of the reader

pub struct NonBlockingReader<R: AsRawFd + Read> {
    eof: bool,
    reader: R,
}

I'm not sure how to make that work with references.
Let me know if you have any ideas, but to me, it seems to me this would be a simple addition to this crate, while I would have to make intrusive changes to nonblock-rs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants