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

Fix some typos #475

Merged
merged 1 commit into from
Nov 19, 2023
Merged
Show file tree
Hide file tree
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
2 changes: 1 addition & 1 deletion reference/src/glossary.md
Original file line number Diff line number Diff line change
Expand Up @@ -145,7 +145,7 @@ It can also be a physical address for bare-level / kernel code. Rust doesn't rea
it's an address as understood by the CPU, it's what the load/store instructions need to identify where in memory to perform the load/store.

Note that a pointer in Rust is *not* just a memory address.
A pointer value consists of a memory address and [provenance][pointer-provenance].
A pointer value consists of a memory address and [provenance][provenance].

### Niche
[niche]: #niche
Expand Down
2 changes: 1 addition & 1 deletion reference/src/layout/scalars.md
Original file line number Diff line number Diff line change
Expand Up @@ -78,7 +78,7 @@ For all Rust's fixed-width integer types `{i,u}{8,16,32,64,128}` it holds that:
* negative values of signed integer types are represented using 2's complement.

Furthermore, Rust's signed and unsigned fixed-width integer types
`{i,u}{8,16,32,64}` have the same layout the C fixed-width integer types from
`{i,u}{8,16,32,64}` have the same layout as the C fixed-width integer types from
the `<stdint.h>` header `{u,}int{8,16,32,64}_t`. These fixed-width integer types
are therefore safe to use directly in C FFI where the corresponding C
fixed-width integer types are expected.
Expand Down
2 changes: 1 addition & 1 deletion reference/src/layout/unions.md
Original file line number Diff line number Diff line change
Expand Up @@ -170,7 +170,7 @@ assert_eq!(size_of::<U>(), 2);
```

**C++ compatibility hazard**: C++ does, in general, give a size of 1 to types
with no fields. When such types are used as an union field in C++, a "naive"
with no fields. When such types are used as a union field in C++, a "naive"
translation of that code into Rust will not produce a compatible result. Refer
to the [struct chapter](structs-and-tuples.md#c-compatible-layout-repr-c) for
further details.
Expand Down
2 changes: 1 addition & 1 deletion reference/src/validity/unions.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ represents the consensus from issue [#73]. The statements in here are not (yet)
## Validity of unions with zero-sized fields

A union containing a zero-sized field can contain any bit pattern. An example of such
an union is [`MaybeUninit`].
a union is [`MaybeUninit`].

[#73]: https://github.com/rust-lang/unsafe-code-guidelines/issues/73
[`MaybeUninit`]: https://doc.rust-lang.org/std/mem/union.MaybeUninit.html