You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue proposes to make the FrameAllocator trait unsafe to implement. This would allow functions to trust FrameAllocator parameters.
Currently it is safe to implement the FrameAllocator trait for a type. So it's entirely possible to safely construct a type that yields the same frame over and over again, even though it is not unused anymore. For this reason, all functions that rely on FrameAllocator parameter should be unsafe because the caller has to guarantee that the passed frame allocator is implemented correctly. If we make the FrameAllocator trait an unsafe trait, we can rule out invalid frame allocators.
This is similar to the Alloc trait of the standard library. Instead of making it safe to implement the trait and mistrusting all Alloc instances, the trait is unsafe so that it can be used in types/functions without making all (constructor) functions unsafe.
This would be a breaking change, but I think that it is worth it. What do you think?
Example
With the current FrameAllocator trait, we have to write code like this:
We can't trust the frame_allocator, because it is possible to create invalid frame allocators in safe code. Therefore, this must be unsafe because the caller has to guarantee that the frame allocator is valid.
If we make the FrameAllocator trait unsafe to implement, the create_mapping function can be safe:
71: Make FrameAllocator an unsafe trait r=phil-opp a=phil-opp
This is a breaking change.
Fixes#69
Co-authored-by: Philipp Oppermann <[email protected]>
This issue proposes to make the
FrameAllocator
traitunsafe
to implement. This would allow functions to trustFrameAllocator
parameters.Currently it is safe to implement the
FrameAllocator
trait for a type. So it's entirely possible to safely construct a type that yields the same frame over and over again, even though it is not unused anymore. For this reason, all functions that rely onFrameAllocator
parameter should be unsafe because the caller has to guarantee that the passed frame allocator is implemented correctly. If we make theFrameAllocator
trait an unsafe trait, we can rule out invalid frame allocators.This is similar to the
Alloc
trait of the standard library. Instead of making it safe to implement the trait and mistrusting allAlloc
instances, the trait is unsafe so that it can be used in types/functions without making all (constructor) functions unsafe.This would be a breaking change, but I think that it is worth it. What do you think?
Example
With the current
FrameAllocator
trait, we have to write code like this:We can't trust the
frame_allocator
, because it is possible to create invalid frame allocators in safe code. Therefore, this must be unsafe because the caller has to guarantee that the frame allocator is valid.If we make the
FrameAllocator
trait unsafe to implement, thecreate_mapping
function can be safe:Now we know the
frame_allocator
can be only invalid if somebody messed up inside an unsafe block (when implementing the trait).The text was updated successfully, but these errors were encountered: