]>
Commit | Line | Data |
---|---|---|
041b39d2 XL |
1 | ## Behavior not considered `unsafe` |
2 | ||
3 | The Rust compiler does not consider the following behaviors _unsafe_, | |
4 | though a programmer may (should) find them undesirable, unexpected, | |
5 | or erroneous. | |
6 | ||
7 | ##### Deadlocks | |
8 | ##### Leaks of memory and other resources | |
9 | ##### Exiting without calling destructors | |
10 | ##### Exposing randomized base addresses through pointer leaks | |
11 | ##### Integer overflow | |
12 | ||
13 | If a program contains arithmetic overflow, the programmer has made an | |
14 | error. In the following discussion, we maintain a distinction between | |
15 | arithmetic overflow and wrapping arithmetic. The first is erroneous, | |
16 | while the second is intentional. | |
17 | ||
18 | When the programmer has enabled `debug_assert!` assertions (for | |
19 | example, by enabling a non-optimized build), implementations must | |
20 | insert dynamic checks that `panic` on overflow. Other kinds of builds | |
21 | may result in `panics` or silently wrapped values on overflow, at the | |
22 | implementation's discretion. | |
23 | ||
24 | In the case of implicitly-wrapped overflow, implementations must | |
25 | provide well-defined (even if still considered erroneous) results by | |
26 | using two's complement overflow conventions. | |
27 | ||
28 | The integral types provide inherent methods to allow programmers | |
29 | explicitly to perform wrapping arithmetic. For example, | |
30 | `i32::wrapping_add` provides two's complement, wrapping addition. | |
31 | ||
32 | The standard library also provides a `Wrapping<T>` newtype which | |
33 | ensures all standard arithmetic operations for `T` have wrapping | |
34 | semantics. | |
35 | ||
36 | See [RFC 560] for error conditions, rationale, and more details about | |
37 | integer overflow. | |
8bb4bdeb XL |
38 | |
39 | [RFC 560]: https://github.com/rust-lang/rfcs/blob/master/text/0560-integer-overflow.md |