|
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