dropbox / dropbox/rust-alloc-no-stdlib
Soundness/documentation issue: CallocBackingStore::new is not safety documented and potentially unsound
- 主要言語
- Rust
- スター
- 180
- フォーク
- 21
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
The unsafe function CallocBackingStore::new does not have documentation for its safety invariants - and neither does the `define_allocator_memory_pool` macro calling it.
https://github.com/dropbox/rust-alloc-no-stdlib/blob/6032b6a9b20e03737135c55a0270ccffcc1438ef/src/lib.rs#L41
I believe the safety contract should mention that:
- the caller must guarantee that the allocator passed in can be safely called (including the corner-case of having a 0 argument for size), and returns buffers of the appropriate size.
- the correct relationship between `alloc` and `free` is upheld (free must be a valid function to free the memory allocated by `alloc`)
- computing `num_elements * sizeof(T)` must not overflow -- unless that is checked in the body of the function.
Moreover, using the macro with `malloc` is *always* unsound unless `T` is `MaybeUninit<_>`: `new` will end up creating a reference to a slice of uninitialized data, which is UB.
Even using the function with `calloc` might be unsound if `0` is not a valid bit pattern for `T`.
Similarly, when using a custom allocator, the bitpatterns returned by the custom allocator should be valid for `T`.
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
調査の方向性
src/lib.rs の CallocBackingStore::new と define_allocator_memory_pool マクロの周辺から始めてください。allocator のコールバックと slice がどのように使用されているかを確認し、issue で特定された安全性不変条件を、割り当てと解放の互換性および有効なビットパターンを含めて文書化してください。両方の unsafe エントリポイントが、呼び出し元に必要な保証を明確に示していれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- rust
- 領域
- operating-systems
- issue の種類
- ドキュメント
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100