|
1 | 1 | % No stdlib |
2 | 2 |
|
3 | | -By default, `std` is linked to every Rust crate. In some contexts, |
4 | | -this is undesirable, and can be avoided with the `#![no_std]` |
5 | | -attribute attached to the crate. |
| 3 | +Rust’s standard library provides a lot of useful functionality, but assumes |
| 4 | +support for various features of its host system: threads, networking, heap |
| 5 | +allocation, and others. There are systems that do not have these features, |
| 6 | +however, and Rust can work with those too! To do so, we tell Rust that we |
| 7 | +don’t want to use the standard library via an attribute: `#![no_std]`. |
| 8 | + |
| 9 | +> Note: This feature is technically stable, but there are some caveats. For |
| 10 | +> one, you can build a `#![no_std]` _library_ on stable, but not a _binary_. |
| 11 | +> For details on libraries without the standard library, see [the chapter on |
| 12 | +> `#![no_std]`](using-rust-without-the-standard-library.html) |
6 | 13 |
|
7 | 14 | Obviously there's more to life than just libraries: one can use |
8 | 15 | `#[no_std]` with an executable, controlling the entry point is |
@@ -77,89 +84,3 @@ personality function (see the |
77 | 84 | information), but crates which do not trigger a panic can be assured |
78 | 85 | that this function is never called. The second function, `panic_fmt`, is |
79 | 86 | also used by the failure mechanisms of the compiler. |
80 | | - |
81 | | -## Using libcore |
82 | | - |
83 | | -> **Note**: the core library's structure is unstable, and it is recommended to |
84 | | -> use the standard library instead wherever possible. |
85 | | -
|
86 | | -With the above techniques, we've got a bare-metal executable running some Rust |
87 | | -code. There is a good deal of functionality provided by the standard library, |
88 | | -however, that is necessary to be productive in Rust. If the standard library is |
89 | | -not sufficient, then [libcore](../core/index.html) is designed to be used |
90 | | -instead. |
91 | | - |
92 | | -The core library has very few dependencies and is much more portable than the |
93 | | -standard library itself. Additionally, the core library has most of the |
94 | | -necessary functionality for writing idiomatic and effective Rust code. When |
95 | | -using `#![no_std]`, Rust will automatically inject the `core` crate, like |
96 | | -we do for `std` when we’re using it. |
97 | | - |
98 | | -As an example, here is a program that will calculate the dot product of two |
99 | | -vectors provided from C, using idiomatic Rust practices. |
100 | | - |
101 | | -```rust |
102 | | -# #![feature(libc)] |
103 | | -#![feature(lang_items)] |
104 | | -#![feature(start)] |
105 | | -#![feature(raw)] |
106 | | -#![no_std] |
107 | | - |
108 | | -extern crate libc; |
109 | | - |
110 | | -use core::mem; |
111 | | - |
112 | | -#[no_mangle] |
113 | | -pub extern fn dot_product(a: *const u32, a_len: u32, |
114 | | - b: *const u32, b_len: u32) -> u32 { |
115 | | - use core::raw::Slice; |
116 | | - |
117 | | - // Convert the provided arrays into Rust slices. |
118 | | - // The core::raw module guarantees that the Slice |
119 | | - // structure has the same memory layout as a &[T] |
120 | | - // slice. |
121 | | - // |
122 | | - // This is an unsafe operation because the compiler |
123 | | - // cannot tell the pointers are valid. |
124 | | - let (a_slice, b_slice): (&[u32], &[u32]) = unsafe { |
125 | | - mem::transmute(( |
126 | | - Slice { data: a, len: a_len as usize }, |
127 | | - Slice { data: b, len: b_len as usize }, |
128 | | - )) |
129 | | - }; |
130 | | - |
131 | | - // Iterate over the slices, collecting the result |
132 | | - let mut ret = 0; |
133 | | - for (i, j) in a_slice.iter().zip(b_slice.iter()) { |
134 | | - ret += (*i) * (*j); |
135 | | - } |
136 | | - return ret; |
137 | | -} |
138 | | - |
139 | | -#[lang = "panic_fmt"] |
140 | | -extern fn panic_fmt(args: &core::fmt::Arguments, |
141 | | - file: &str, |
142 | | - line: u32) -> ! { |
143 | | - loop {} |
144 | | -} |
145 | | - |
146 | | -#[lang = "eh_personality"] extern fn eh_personality() {} |
147 | | -# #[start] fn start(argc: isize, argv: *const *const u8) -> isize { 0 } |
148 | | -# #[lang = "eh_unwind_resume"] extern fn rust_eh_unwind_resume() {} |
149 | | -# #[no_mangle] pub extern fn rust_eh_register_frames () {} |
150 | | -# #[no_mangle] pub extern fn rust_eh_unregister_frames () {} |
151 | | -# fn main() {} |
152 | | -``` |
153 | | - |
154 | | -Note that there is one lang item here whose signature differs from the examples |
155 | | -above, `panic_fmt`. This must be defined by consumers of libcore because the |
156 | | -core library declares panics, but it does not define it. The `panic_fmt` |
157 | | -lang item is this crate's definition of panic, and it must be guaranteed to |
158 | | -never return. |
159 | | - |
160 | | -As can be seen in this example, the core library is intended to provide the |
161 | | -power of Rust in all circumstances, regardless of platform requirements. Further |
162 | | -libraries, such as liballoc, add functionality to libcore which make other |
163 | | -platform-specific assumptions, but continue to be more portable than the |
164 | | -standard library itself. |
165 | | - |
0 commit comments