Skip to content

Add UserSlicePtrWriter::clear. #222

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

Merged
merged 1 commit into from
Apr 27, 2021
Merged

Add UserSlicePtrWriter::clear. #222

merged 1 commit into from
Apr 27, 2021

Conversation

wedsonaf
Copy link

Signed-off-by: Wedson Almeida Filho [email protected]

Comment on lines +250 to +260
if len > self.1 {
ret = Err(Error::EFAULT);
len = self.1;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the documentation should explain the behavior better, i.e. that it will clear no matter what, even if the length is bigger and that the fields will be updated in all cases.

In any case, isn't a bit confusing to do that given write_raw() will return without performing any action if len is out of bounds? (Which, by the way, should likely be a EINVAL rather than a EFAULT, no?)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the documentation should explain the behavior better, i.e. that it will clear no matter what, even if the length is bigger and that the fields will be updated in all cases.

Sure. I updated the documentation.

In any case, isn't a bit confusing to do that given write_raw() will return without performing any action if len is out of bounds?

Since write_raw doesn't update its internal state to reflect partial writes, it not so problematic at the moment.

For clear we need to report how much was actually cleared because we want to mimic the behaviour of the C implementation.

I agree that it isn't ideal, but I think the solution here is really to update write_raw to reflect what was written in its internal state. But since this PR is about clear, I think this should be updated in another PR.

(Which, by the way, should likely be a EINVAL rather than a EFAULT, no?)

Perhaps. But I think EINVAL, if bubbled up to userspace, is too generic. EFAULT is a better indication that the problem is in some address. Also, this is the existing behaviour, I'm just trying to add clear.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! It is clear now.

Signed-off-by: Wedson Almeida Filho <[email protected]>
@ojeda
Copy link
Member

ojeda commented Apr 27, 2021

Reviewed-by: Miguel Ojeda <[email protected]>

@ojeda ojeda merged commit e3dea04 into Rust-for-Linux:rust Apr 27, 2021
@wedsonaf wedsonaf deleted the clear branch April 28, 2021 13:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants