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

Use Option in return type for SingleRegisterAccess::read_register #110

Closed
daniel5151 opened this issue Jul 28, 2022 · 1 comment
Closed
Labels
API-breaking Breaking API change API-ergonomics Nothing's "broken", but the API could be improved wontfix This will not be worked on
Milestone

Comments

@daniel5151
Copy link
Owner

#107 has introduced an in-band mechanism of signaling cases where a single register is recognized but unavailable (i.e: returning Ok(0) from the fn)

In the next breaking version of gdbstub, this should be changed to use Option instead, making it clearer that this feature exists.

@daniel5151 daniel5151 added good first issue Good for newcomers API-ergonomics Nothing's "broken", but the API could be improved API-breaking Breaking API change labels Jul 28, 2022
@daniel5151 daniel5151 added this to the 0.7 milestone Jul 28, 2022
@daniel5151 daniel5151 added wontfix This will not be worked on and removed good first issue Good for newcomers labels Apr 29, 2023
@daniel5151
Copy link
Owner Author

On further consideration, I think I've convinced myself that using Ok(0) to report valid but unavailable registers is actually quite reasonable.

If you think about it, read_register's API is quite similar to something like std::io::Read, where you're asked to fill up a buffer, and return a usize indicating how much data was written. With this perspective, returning 0 seems totally reasonable.

So I think I'll be closing out this issue as "won't fix"

@daniel5151 daniel5151 closed this as not planned Won't fix, can't repro, duplicate, stale Apr 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API-breaking Breaking API change API-ergonomics Nothing's "broken", but the API could be improved wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant