Skip to content

Commit

Permalink
Merge branch 'master' into Nadrieril-patch-1
Browse files Browse the repository at this point in the history
  • Loading branch information
Nadrieril authored Aug 10, 2024
2 parents 6b9582a + 9f871ce commit 1930024
Show file tree
Hide file tree
Showing 4 changed files with 20 additions and 8 deletions.
11 changes: 8 additions & 3 deletions src/beneath-std.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,10 @@ Note that the default features have been disabled. This is a critical step -
disabled.**

Alternatively, we can use the unstable `rustc_private` private feature together
with an `extern crate libc;` declaration as shown in the examples below.
with an `extern crate libc;` declaration as shown in the examples below. Note that
windows-msvc targets do not require a libc, and correspondingly there is no `libc`
crate in their sysroot. We do not need the `extern crate libc;` below, and having it
on a windows-msvc target would be a compile error.

## Writing an executable without `std`

Expand All @@ -39,11 +42,12 @@ in the same format as C (aside from the exact integer types being used):
#![allow(internal_features)]
#![no_std]

// Necessary for `panic = "unwind"` builds on some platforms.
// Necessary for `panic = "unwind"` builds on cfg(unix) platforms.
#![feature(panic_unwind)]
extern crate unwind;

// Pull in the system libc library for what crt0.o likely requires.
#[cfg(not(windows))]
extern crate libc;

use core::panic::PanicInfo;
Expand Down Expand Up @@ -73,11 +77,12 @@ compiler's name mangling too:
#![no_std]
#![no_main]

// Necessary for `panic = "unwind"` builds on some platforms.
// Necessary for `panic = "unwind"` builds on cfg(unix) platforms.
#![feature(panic_unwind)]
extern crate unwind;

// Pull in the system libc library for what crt0.o likely requires.
#[cfg(not(windows))]
extern crate libc;

use core::ffi::{c_char, c_int};
Expand Down
6 changes: 3 additions & 3 deletions src/other-reprs.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ says they should still consume a byte of space.
difference from a struct is that the fields aren’t named.

* `repr(C)` is equivalent to one of `repr(u*)` (see the next section) for
fieldless enums. The chosen size is the default enum size for the target platform's C
fieldless enums. The chosen size and sign is the default enum size and sign for the target platform's C
application binary interface (ABI). Note that enum representation in C is implementation
defined, so this is really a "best guess". In particular, this may be incorrect
when the C code of interest is compiled with certain flags.
Expand Down Expand Up @@ -79,7 +79,7 @@ More details are in the [RFC 1758][rfc-transparent] and the [RFC 2645][rfc-trans

## repr(u*), repr(i*)

These specify the size to make a fieldless enum. If the discriminant overflows
These specify the size and sign to make a fieldless enum. If the discriminant overflows
the integer it has to fit in, it will produce a compile-time error. You can
manually ask Rust to allow this by setting the overflowing element to explicitly
be 0. However Rust will not allow you to create an enum where two variants have
Expand All @@ -89,7 +89,7 @@ The term "fieldless enum" only means that the enum doesn't have data in any
of its variants. A fieldless enum without a `repr(u*)` or `repr(C)` is
still a Rust native type, and does not have a stable ABI representation.
Adding a `repr` causes it to be treated exactly like the specified
integer size for ABI purposes.
integer type for ABI purposes.

If the enum has fields, the effect is similar to the effect of `repr(C)`
in that there is a defined layout of the type. This makes it possible to
Expand Down
2 changes: 1 addition & 1 deletion src/subtyping.md
Original file line number Diff line number Diff line change
Expand Up @@ -268,7 +268,7 @@ To see why `fn(T) -> U` should be covariant over `U`, consider the following sig
fn get_str() -> &'a str;
```

This function claims to produce a `str` bound by some liftime `'a`. As such, it is perfectly valid to
This function claims to produce a `str` bound by some lifetime `'a`. As such, it is perfectly valid to
provide a function with the following signature instead:

<!-- ignore: simplified code -->
Expand Down
9 changes: 8 additions & 1 deletion src/what-unsafe-does.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ The only things that are different in Unsafe Rust are that you can:
* Dereference raw pointers
* Call `unsafe` functions (including C functions, compiler intrinsics, and the raw allocator)
* Implement `unsafe` traits
* Mutate statics
* Access or modify mutable statics
* Access fields of `union`s

That's it. The reason these operations are relegated to Unsafe is that misusing
Expand Down Expand Up @@ -41,6 +41,9 @@ language cares about is preventing the following things:
[`NonNull`] that is null. (Requesting custom invalid values is an unstable
feature, but some stable libstd types, like `NonNull`, make use of it.)

For a more detailed explanation about "Undefined Bahavior", you may refer to
[the reference][behavior-considered-undefined].

"Producing" a value happens any time a value is assigned, passed to a
function/primitive operation or returned from a function/primitive operation.

Expand Down Expand Up @@ -75,6 +78,8 @@ Rust considers it "safe" to:
* Abort the program
* Delete the production database

For more detailed information, you may refer to [the reference][behavior-not-considered-unsafe].

However any program that actually manages to do such a thing is *probably*
incorrect. Rust provides lots of tools to make these things rare, but
these problems are considered impractical to categorically prevent.
Expand All @@ -84,3 +89,5 @@ these problems are considered impractical to categorically prevent.
[race]: races.html
[target features]: ../reference/attributes/codegen.html#the-target_feature-attribute
[`NonNull`]: ../std/ptr/struct.NonNull.html
[behavior-considered-undefined]: ../reference/behavior-considered-undefined.html
[behavior-not-considered-unsafe]: ../reference/behavior-not-considered-unsafe.html

0 comments on commit 1930024

Please sign in to comment.