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

Add a challenge for linked_list #30

Merged
merged 3 commits into from
Jul 10, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions doc/src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,3 +15,4 @@
- [Challenges](./challenges.md)
- [Core Transmutation](./challenges/0001-core-transmutation.md)
- [Memory safety of core intrinsics](./challenges/0002-intrinsics-memory.md)
- [Inductive data type](./challenges/0005-linked-list.md)
48 changes: 48 additions & 0 deletions doc/src/challenges/0005-linked-list.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
# Challenge 5: Verify functions iterating over inductive data type: `linked_list`

- **Status:** Open
- **Tracking Issue:** [Link to issue](https://github.com/model-checking/verify-rust-std/issues/29)
- **Start date:** *24/07/01*
- **End date:** *24/12/10*

-------------------


## Goal

Verify the memory safety of [`alloc::collections::linked_list` functions](https://github.com/rust-lang/rust/blob/c290e9de32e8ba6a673ef125fde40eadd395d170/library/alloc/src/collections/linked_list.rs) that iterate the its internal inductive-defined data type.

### Details

The internal representations of `linked_list` are bi-direction linked list nodes. To unboundedly prove the memory safety of functions that iterating over such inductive-defined data type, we need to illustrate the memory safety for linked lists of arbitrary shape. On the other hand, if we can only prove the memory safety for certain shapes of linked lists, how should we specify the precondition---the assumptions on the shape of the inductive-defined data type---of such functions.


### Success Criteria

The memory safety of all public functions that iterating over the internal inductive data type must be verified, e.g.:
celinval marked this conversation as resolved.
Show resolved Hide resolved

| Function | Location |
|---------|---------|
|clearn | alloc::collections::linked_list |
|contains| alloc::collections::linked_list |
|split_off| alloc::collections::linked_list |
|remove| alloc::collections::linked_list |
|retain| alloc::collections::linked_list |
|retain_mut| alloc::collections::linked_list |
|extract_if| alloc::collections::linked_list |


The verification must be unbounded---it must hold for linked lists of arbitrary shape.
celinval marked this conversation as resolved.
Show resolved Hide resolved

### List of UBs

All proofs must automatically ensure the absence of the following undefined behaviors [ref](https://github.com/rust-lang/reference/blob/142b2ed77d33f37a9973772bd95e6144ed9dce43/src/behavior-considered-undefined.md):

* Accessing (loading from or storing to) a place that is dangling or based on a misaligned pointer.
* Reading from uninitialized memory except for padding or unions.
* Mutating immutable bytes.
* Producing an invalid value


Note: All solutions to verification challenges need to satisfy the criteria established in the [challenge book](../general-rules.md)
in addition to the ones listed above.
Loading