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
The goal of this challenge is to verify the [flt2dec](https://doc.rust-lang.org/src/core/num/flt2dec/mod.rs.html) module, which provides functions for converting floating point numbers to decimals. To do this, it implements both the Dragon and Grisu families of algorithms.
16
+
17
+
## Motivation
18
+
19
+
Given that converting floats to decimals correctly is a relatively costly operation, the standard library’s flt2dec module employs unsafe code to enable performance-enhancing operations that are otherwise not allowed in safe Rust (e.g., lifetime laundering to get around borrow-checker restrictions). Functions from this module are primarily invoked whenever attempting to represent floats in a human-readable format, making this a potentially highly-used module.
20
+
21
+
## Description
22
+
23
+
All of the functions targeted in this challenge are safe functions whose bodies contain unsafe code. This challenge is thus centered around proving well-encapsulation, which here mainly means showing that calls to variants of assume_init() are only performed on fully-initialized structures, and that the lifetime laundering does not cause undefined behaviour.
24
+
25
+
### Success Criteria
26
+
27
+
The following functions contain unsafe code in their bodies but are not themselves marked unsafe. All of these should be proven unconditionally safe, or safety contracts should be added:
For functions taking inputs of generic type 'T', the proofs can be limited to primitive types only.
45
+
46
+
*List of UBs*
47
+
48
+
In addition to any properties called out as SAFETY comments in the source code, all proofs must automatically ensure the absence of the following [undefined behaviors](https://github.com/rust-lang/reference/blob/142b2ed77d33f37a9973772bd95e6144ed9dce43/src/behavior-considered-undefined.md):
49
+
* Accessing (loading from or storing to) a place that is dangling or based on a misaligned pointer.
50
+
* Invoking undefined behavior via compiler intrinsics.
51
+
* Mutating immutable bytes.
52
+
* Producing an invalid value.
53
+
54
+
Note: All solutions to verification challenges need to satisfy the criteria established in the [challenge book](../general-rules.md)
The goal of this challenge is to verify the [boxed](https://doc.rust-lang.org/std/boxed/index.html) module, which implements the Box family of types (which includes Box and other related types such as ThinBox). A Box is a type of smart pointer that points to a uniquely-owned heap allocation for arbitrary types.
16
+
17
+
## Motivation
18
+
19
+
A Box allows the storage of data on the heap rather than the stack. This has several applications, a common [example](https://doc.rust-lang.org/book/ch15-01-box.html#enabling-recursive-types-with-boxes) being for using dynamically-sized types in contexts requiring an exact size (e.g., recursive types). While this type is useful and diverse in its applications, it also extensively uses unsafe code, meaning it is important to verify that this module is free of undefined behaviour.
20
+
21
+
### Success Criteria
22
+
23
+
All the following unsafe functions must be annotated with safety contracts and the contracts have been verified:
The following functions contain unsafe code in their bodies but are not themselves marked unsafe. At least 75% of these should be proven unconditionally safe, or safety contracts should be added:
For functions taking inputs of generic type 'T', the proofs can be limited to primitive types only.
89
+
90
+
*List of UBs*
91
+
92
+
In addition to any properties called out as SAFETY comments in the source code, all proofs must automatically ensure the absence of the following [undefined behaviors](https://github.com/rust-lang/reference/blob/142b2ed77d33f37a9973772bd95e6144ed9dce43/src/behavior-considered-undefined.md):
93
+
* Accessing (loading from or storing to) a place that is dangling or based on a misaligned pointer.
94
+
* Invoking undefined behavior via compiler intrinsics.
95
+
* Mutating immutable bytes.
96
+
* Producing an invalid value.
97
+
98
+
Note: All solutions to verification challenges need to satisfy the criteria established in the [challenge book](../general-rules.md)
0 commit comments