Skip to content

Commit d4b0ece

Browse files
authored
Fix grammar and typos in safe-unsafe-meaning.md
1 parent 5b3a9d0 commit d4b0ece

1 file changed

Lines changed: 5 additions & 5 deletions

File tree

src/safe-unsafe-meaning.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@ The standard library has a number of unsafe functions, including:
4141
* All FFI (Foreign Function Interface) functions are `unsafe` to call because the
4242
other language can do arbitrary operations that the Rust compiler can't check.
4343

44-
As of Rust 1.29.2 the standard library defines the following unsafe traits
44+
As of Rust 1.29.2, the standard library defines the following unsafe traits
4545
(there are others, but they are not stabilized yet and some of them may never
4646
be):
4747

@@ -55,7 +55,7 @@ Much of the Rust standard library also uses Unsafe Rust internally. These
5555
implementations have generally been rigorously manually checked, so the Safe Rust
5656
interfaces built on top of these implementations can be assumed to be safe.
5757

58-
The need for all of this separation boils down a single fundamental property
58+
The need for all of this separation boils down to a single fundamental property
5959
of Safe Rust, the *soundness property*:
6060

6161
**No matter what, Safe Rust can't cause Undefined Behavior.**
@@ -129,9 +129,9 @@ traits `unsafe` because it makes Unsafe Rust pervasive, which isn't desirable.
129129

130130
`Send` and `Sync` are marked unsafe because thread safety is a *fundamental
131131
property* that unsafe code can't possibly hope to defend against in the way it
132-
could defend against a buggy `Ord` implementation. Similarly, `GlobalAllocator`
132+
could defend against a buggy `Ord` implementation. Similarly, `GlobalAlloc`
133133
is keeping accounts of all the memory in the program and other things like
134-
`Box` or `Vec` build on top of it. If it does something weird (giving the same
134+
`Box` or `Vec` that build on top of it. If it does something weird (giving the same
135135
chunk of memory to another request when it is still in use), there's no chance
136136
to detect that and do anything about it.
137137

@@ -141,7 +141,7 @@ against a broken implementation of the trait, then marking the trait `unsafe` is
141141
a reasonable choice.
142142

143143
As an aside, while `Send` and `Sync` are `unsafe` traits, they are *also*
144-
automatically implemented for types when such derivations are provably safe
144+
automatically implemented for types when such derivations are probably safe
145145
to do. `Send` is automatically derived for all types composed only of values
146146
whose types also implement `Send`. `Sync` is automatically derived for all
147147
types composed only of values whose types also implement `Sync`. This minimizes

0 commit comments

Comments
 (0)