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.

Sign up for GitHub

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

Jump to bottom

Define a separate trait for reading objects that know when to stop vs not #3292

Open
TheBlueMatt opened this issue Sep 4, 2024 · 4 comments · May be fixed by #3640
Open

Define a separate trait for reading objects that know when to stop vs not #3292

TheBlueMatt opened this issue Sep 4, 2024 · 4 comments · May be fixed by #3640
Labels
Take a Friday Leave a Friday Stomp the Bugs, Without Much Commitment

Comments

@TheBlueMatt
Copy link
Collaborator

We currently have one trait (Readable) for reading objects with two totally different semantics - objects may know when to stop reading cause they have length descriptors and some objects may not (cause they just read to end). We should really have two different traits for the two types of objects cause its unsafe to confuse them.
@TheBlueMatt TheBlueMatt added the Take a Friday Leave a Friday Stomp the Bugs, Without Much Commitment label Sep 4, 2024
@acceleratesage
Copy link

Could you be more specific about the cases where this leads to unsafe situations?

@vincenzopalazzo
Copy link
Contributor

Could you be more specific about the cases where this leads to unsafe situations?

probably when you mix the two types, but I could be wrong

@acceleratesage
Copy link

I don't see how that would be any more unsafe than reading smth. from a stream in general. It's either long enough, or it isn't. If you try to read something after reading an object that reads to the end, the stream has no data left. I may be missing something here. Maybe Matt had a more specific example in mind?

@TheBlueMatt
Copy link
Collaborator Author

Its not "unsafe" in the Rust "can lead to language-undefined behavior" definition, but rather unsafe in the "can lead to bugs" sense. If you have an object which is being read and it tries to read some sub-object which unexpectedly consumes the whole stream things may spuriously fail to deserialize or read the wrong fields.

@valentinewallace valentinewallace linked a pull request Mar 3, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Take a Friday Leave a Friday Stomp the Bugs, Without Much Commitment
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Require FixedLengthReadable for structs that always drain reader valentinewallace/rust-lightning
3 participants
@acceleratesage @TheBlueMatt @vincenzopalazzo