Skip to content

doc: clarifying unsafe code vs undefined behavior #19105

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

Merged
merged 1 commit into from
Nov 20, 2014
Merged
Changes from all commits
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
17 changes: 8 additions & 9 deletions src/doc/reference.md
Original file line number Diff line number Diff line change
Expand Up @@ -1117,13 +1117,13 @@ Rust:
##### Unsafe functions

Unsafe functions are functions that are not safe in all contexts and/or for all
possible inputs. Such a function must be prefixed with the keyword `unsafe`.
possible inputs. Such a function must be prefixed with the keyword `unsafe` and
can only be called from an `unsafe` block or another `unsafe` function.

##### Unsafe blocks

A block of code can also be prefixed with the `unsafe` keyword, to permit
calling `unsafe` functions or dereferencing raw pointers within a safe
function.
A block of code can be prefixed with the `unsafe` keyword, to permit calling
`unsafe` functions or dereferencing raw pointers within a safe function.

When a programmer has sufficient conviction that a sequence of potentially
unsafe operations is actually safe, they can encapsulate that sequence (taken
Expand All @@ -1143,12 +1143,11 @@ represented with reference-counted pointers in safe code. By using `unsafe`
blocks to represent the reverse links as raw pointers, it can be implemented
with only boxes.

##### Behavior considered unsafe
##### Behavior considered undefined

This is a list of behavior which is forbidden in all Rust code. Type checking
provides the guarantee that these issues are never caused by safe code. An
`unsafe` block or function is responsible for never invoking this behaviour or
exposing an API making it possible for it to occur in safe code.
The following is a list of behavior which is forbidden in all Rust code,
including within `unsafe` blocks and `unsafe` functions. Type checking provides
the guarantee that these issues are never caused by safe code.

* Data races
* Dereferencing a null/dangling raw pointer
Expand Down