-
Notifications
You must be signed in to change notification settings - Fork 1
Split standard_b64encode_impl #17
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
Split standard_b64encode_impl #17
Conversation
8bb35a3 to
ed31a89
Compare
Eclips4
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
That looks much better.
ed31a89 to
5d45c51
Compare
Modules/_base64/src/lib.rs
Outdated
| fn from_object(obj: &PyObject) -> Result<Self, ()> { | ||
| let mut view = MaybeUninit::<Py_buffer>::uninit(); | ||
| if unsafe { PyObject_GetBuffer(obj, view.as_mut_ptr(), PYBUF_SIMPLE) } != 0 { | ||
| if unsafe { PyObject_GetBuffer(obj as *const _ as *mut _, view.as_mut_ptr(), PYBUF_SIMPLE) } != 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Passing Rc::into_raw() is the right interface. But this patch doesn't include Rc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new interface guarantees there is no mutating to PyObject on Rust side. mutating in C side is okay as before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you could expose .raw_get() from the inner UnsafeCell to get a *mut _object, but I guess that won't work as I assume PyObject_GetBuffer expects a *mut PyObject, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right. But the idea using .raw() and encapsulating it from PyObject is also a better idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added PyObject::as_raw(). Please give it a better name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@emmatyping is there more issues to fix?
standard_b64encode is inherently an unsafe function. Meanwhile, standard_b64encode_impl uses unsafe operations internally, but it is intended to be a function where the programmer guarantees its safety. By separating these two functions, we can ensure that the truly safe parts of standard_b64encode_impl remain outside the unsafe block.
BorrowedBuffer::from_object is actually safe as long as the pointer to the object remains valid. In this case, it seems better to require the caller to ensure pointer validity rather than hiding that requirement inside the function itself.