about summary refs log tree commit diff
path: root/library/std/src/os
AgeCommit message (Collapse)AuthorLines
2021-05-15Auto merge of #81858 - ijackson:fork-no-unwind, r=m-ou-sebors-0/+6
Do not allocate or unwind after fork ### Objective scenarios * Make (simple) panics safe in `Command::pre_exec_hook`, including most `panic!` calls, `Option::unwrap`, and array bounds check failures. * Make it possible to `libc::fork` and then safely panic in the child (needed for the above, but this requirement means exposing the new raw hook API which the `Command` implementation needs). * In singlethreaded programs, where panic in `pre_exec_hook` is already memory-safe, prevent the double-unwinding malfunction #79740. I think we want to make panic after fork safe even though the post-fork child environment is only experienced by users of `unsafe`, beause the subset of Rust in which any panic is UB is really far too hazardous and unnatural. #### Approach * Provide a way for a program to, at runtime, switch to having panics abort. This makes it possible to panic without making *any* heap allocations, which is needed because on some platforms malloc is UB in a child forked from a multithreaded program (see https://github.com/rust-lang/rust/pull/80263#issuecomment-774272370, and maybe also the SuS [spec](https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html)). * Make that change in the child spawned by `Command`. * Document the rules comprehensively enough that a programmer has a fighting chance of writing correct code. * Test that this all works as expected (and in particular, that there aren't any heap allocations we missed) Fixes #79740 #### Rejected (or previously attempted) approaches * Change the panic machinery to be able to unwind without allocating, at least when the payload and message are both `'static`. This seems like it would be even more subtle. Also that is a potentially-hot path which I don't want to mess with. * Change the existing panic hook mechanism to not convert the message to a `String` before calling the hook. This would be a surprising change for existing code and would not be detected by the type system. * Provide a `raw_panic_hook` function to intercept panics in a way that doesn't allocate. (That was an earlier version of this MR.) ### History This MR could be considered a v2 of #80263. Thanks to everyone who commented there. In particular, thanks to `@m-ou-se,` `@Mark-Simulacrum` and `@hyd-dev.` (Tagging you since I think you might be interested in this new MR.) Compared to #80263, this MR has very substantial changes and additions. Additionally, I have recently (2021-04-20) completely revised this series following very helpful comments from `@m-ou-se.` r? `@m-ou-se`
2021-05-14Expand WASI abbreviation in docsr00ster-1/+1
2021-05-12ExitStatusError: Remove mentions in stable docsIan Jackson-27/+3
We should revert this commit when this is stabilised. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-12unix: impl ExitStatusExt for ExitStatusErrorIan Jackson-7/+70
It is unergnomic to have to say things like bad.into_status().signal() Implementing `ExitStatusExt` for `ExitStatusError` fixes this. Unfortunately it does mean making a previously-infallible method capable of panicing, although of course the existing impl remains infallible. The alternative would be a whole new `ExitStatusErrorExt` trait. `<ExitStatus as ExitStatusExt>::into_raw()` is not particularly ergonomic to call because of the often-required type annotation. See for example the code in the test case in library/std/src/sys/unix/process/process_unix/tests.rs Perhaps we should provide equivalent free functions for `ExitStatus` and `ExitStatusExt` in std::os::unix::process and maybe deprecate this trait method. But I think that is for the future. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-11Remove an invalid `#[doc(inline)]`LeSeulArtichaut-1/+0
2021-05-07Revert SGX inline asm syntaxJethro Beekman-6/+6
This was erroneously changed in #83387
2021-05-07unix process: pre_exec: Discuss panic safetyIan Jackson-0/+6
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2021-05-03Allow documenting on `hermit`Christiaan Dirkx-2/+0
2021-05-03Rework `os` to avoid using `cfg_if!` with public itemsChristiaan Dirkx-123/+151
2021-05-03Move `std::sys::sgx::ext` to `std::os::fortanix_sgx`Christiaan Dirkx-2/+265
2021-05-03Move `std::sys::wasi::ext` to `std::os::wasi`Christiaan Dirkx-8/+797
2021-05-03Move `std::sys::unix::ext` to `std::os::unix`Christiaan Dirkx-4/+5374
2021-05-03Move `std::sys::windows::ext` to `std::os::windows`Christiaan Dirkx-4/+1145
2021-05-03Move `std::sys::hermit::ext` to `std::os::hermit`Christiaan Dirkx-1/+57
2021-05-03Cleanup `std::os`Christiaan Dirkx-76/+90
2021-03-16Deprecate std::os::haiku::rawbstrie-0/+7
2021-03-03Rollup merge of #82712 - CDirkx:cfg-target_os, r=dtolnayYuki Okushi-1/+1
Remove unnecessary conditional `cfg(target_os)` for `redox` and `vxworks` `redox` and `vxworks` are now part of target_family `unix`, thus `cfg(unix)` already implies `cfg(target_os="redox")` and `cfg(target_os="vxworks")` https://github.com/rust-lang/rust/blob/35dbef235048f9a2939dc20effe083ca483c37ff/compiler/rustc_target/src/spec/redox_base.rs#L26 https://github.com/rust-lang/rust/blob/35dbef235048f9a2939dc20effe083ca483c37ff/compiler/rustc_target/src/spec/vxworks_base.rs#L27
2021-03-03Remove unnecessary conditional `cfg(target_os)` for `redox` and `vxworks`Christiaan Dirkx-1/+1
`redox` and `vxworks` are part of target_family `unix`, thus `cfg(unix)` already implies `cfg(target_os="redox")` and `(target_os="vxworks")`
2021-03-01Add missing stability attributes in libstdGuillaume Gomez-0/+1
2021-02-27Rollup merge of #82420 - sunfishcode:wasi-docs, r=alexcrichtonDylan DPC-3/+8
Enable API documentation for `std::os::wasi`. This adds API documentation support for `std::os::wasi` modeled after how `std::os::unix` works, so that WASI can be documented [here] along with the other platforms. [here]: https://doc.rust-lang.org/stable/std/os/index.html Two changes of particular interest: - This changes the `AsRawFd` for `io::Stdin` for WASI to return `libc::STDIN_FILENO` instead of `sys::stdio::Stdin.as_raw_fd()` (and similar for `Stdout` and `Stderr`), which matches how the `unix` version works. `STDIN_FILENO` etc. may not always be explicitly reserved at the WASI level, but as long as we have Rust's `std` and `libc`, I think it's reasonable to guarantee that we'll always use `libc::STDIN_FILENO` for stdin. - This duplicates the `osstr2str` utility function, rather than trying to share it across all the configurations that need it. r? ```@alexcrichton```
2021-02-24Mention "wasi" in the comment about "main modules".Dan Gohman-1/+1
2021-02-24Make the main `wasi` module `cfg(not(doc))`.Dan Gohman-2/+4
2021-02-23Use #[doc = include_str!()] in stdLeSeulArtichaut-1/+1
2021-02-23Enable API documentation for `std::os::wasi`.Dan Gohman-0/+3
This adds API documentation support for `std::os::wasi` modeled after how `std::os::unix` works, so that WASI can be documented [here] along with the other platforms. [here]: https://doc.rust-lang.org/stable/std/os/index.html Two changes of particular interest: - This changes the `AsRawFd` for `io::Stdin` for WASI to return `libc::STDIN_FILENO` instead of `sys::stdio::Stdin.as_raw_fd()` (and similar for `Stdout` and `Stderr`), which matches how the `unix` version works. `STDIN_FILENO` etc. may not always be explicitly reserved at the WASI level, but as long as we have Rust's `std` and `libc`, I think it's reasonable to guarantee that we'll always use `libc::STDIN_FILENO` for stdin. - This duplicates the `osstr2str` utility function, rather than trying to share it across all the configurations that need it.
2021-02-22Avoid `cfg_if` in `std::os`Jonas Schievink-27/+27
2021-02-21update tracking issue for raw_os_nonzeroAshley Mannix-1/+1
2021-02-17Provide NonZero_c_* integersIan Jackson-18/+47
I'm pretty sure I am going want this for #73125 and it seems like an omission that would be in any case good to remedy. It's a shame we don't have competent token pasting and case mangling for use in macro_rules!. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-02-17std::src::os::raw: Refactor, introducing macro type_alias!Ian Jackson-54/+27
This file contained a lot of repetitive code. This was about to get considerably worse, with introduction of a slew of new aliases. No functional change. I've eyeballed the docs and they don't seem to have changed either. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-02-02Fix AArch64 types in std::os::rawAmanieu d'Antras-8/+8
2020-10-16Take sys/vxworks/{fd,fs,io} from sys/unix instead.Mara Bos-0/+18
2020-10-09doc: disambiguate stat in MetadataExt::as_raw_statJosh Stone-1/+1
A few architectures in `os::linux::raw` import `libc::stat`, rather than defining that type directly. However, that also imports the _function_ called `stat`, which makes this doc link ambiguous: error: `crate::os::linux::raw::stat` is both a struct and a function --> library/std/src/os/linux/fs.rs:21:19 | 21 | /// [`stat`]: crate::os::linux::raw::stat | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ambiguous link | = note: `-D broken-intra-doc-links` implied by `-D warnings` help: to link to the struct, prefix with the item type | 21 | /// [`stat`]: struct@crate::os::linux::raw::stat | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: to link to the function, add parentheses | 21 | /// [`stat`]: crate::os::linux::raw::stat() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ We want the `struct`, so it's now prefixed accordingly.
2020-09-28library/std: Set OS raw type definitions for sparc-unknown-linux-gnuJohn Paul Adrian Glaubitz-0/+1
2020-09-16library/std: raw: Add support for RISC-V 32-bitAlistair Francis-2/+4
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-16library/std: linux: Add support for RISC-V 32-bitAlistair Francis-1/+2
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-09-11Update `std::os` module documentation.Christiaan Dirkx-2/+4
Adds missing descriptions for the modules std::os::linux::fs and std::os::windows::io. Also adds punctuation for consistency with other descriptions.
2020-09-04Remove a useless allowed attrLzu Tao-2/+0
2020-09-03Auto merge of #73819 - euclio:rustdoc-summaries, r=jyn514,GuillaumeGomezbors-6/+6
rustdoc: do not use plain summary for trait impls Fixes #38386. Fixes #48332. Fixes #49430. Fixes #62741. Fixes #73474. Unfortunately this is not quite ready to go because the newly-working links trigger a bunch of linkcheck failures. The failures are tough to fix because the links are resolved relative to the implementor, which could be anywhere in the module hierarchy. (In the current docs, these links end up rendering as uninterpreted markdown syntax, so I don't think these failures are any worse than the status quo. It might be acceptable to just add them to the linkchecker whitelist.) Ideally this could be fixed with intra-doc links ~~but it isn't working for me: I am currently investigating if it's possible to solve it this way.~~ Opened #73829. EDIT: This is now ready!
2020-08-31std: move "mod tests/benches" to separate filesLzu Tao-21/+20
Also doing fmt inplace as requested.
2020-08-30fix broken trait method linksAndy Russell-6/+6
2020-08-27Rollup merge of #74730 - androm3da:fix_libstd_hexlinux_01, r=dtolnayDylan DPC-24/+24
Hexagon libstd: update type defs
2020-08-15Auto merge of #74576 - myfreeweb:freebsd-sanitizers, r=oli-obkbors-1/+13
Add sanitizer support on FreeBSD Restarting #47337. Everything is better now, no more weird llvm problems, well not everything: Unfortunately, the sanitizers don't have proper support for versioned symbols (https://github.com/google/sanitizers/issues/628), so `libc`'s usage of `stat@FBSD_1.0` and so on explodes, e.g. in calling `std::fs::metadata`. Building std (now easy thanks to cargo `-Zbuild-std`) and libc with `freebsd12/13` config via the `LIBC_CI=1` env variable is a good workaround… ``` LIBC_CI=1 RUSTFLAGS="-Z sanitizer=address" cargo +san-test -Zbuild-std run --target x86_64-unknown-freebsd --verbose ``` …*except* std won't build because there's no `st_lspare` in the ino64 version of the struct, so an std patch is required: ```diff --- i/src/libstd/os/freebsd/fs.rs +++ w/src/libstd/os/freebsd/fs.rs @@ -66,8 +66,6 @@ pub trait MetadataExt { fn st_flags(&self) -> u32; #[stable(feature = "metadata_ext2", since = "1.8.0")] fn st_gen(&self) -> u32; - #[stable(feature = "metadata_ext2", since = "1.8.0")] - fn st_lspare(&self) -> u32; } #[stable(feature = "metadata_ext", since = "1.1.0")] @@ -136,7 +134,4 @@ impl MetadataExt for Metadata { fn st_flags(&self) -> u32 { self.as_inner().as_inner().st_flags as u32 } - fn st_lspare(&self) -> u32 { - self.as_inner().as_inner().st_lspare as u32 - } } ``` I guess std could like.. detect that `libc` isn't built for the old ABI, and replace the implementation of `st_lspare` with a panic?
2020-08-14remove primitive type linksPrabakaran Kumaresshan-20/+0
2020-08-14Switch to intra-doc links in os/raw/*.mdPrabakaran Kumaresshan-33/+33
2020-08-11Revert #tymethodsPrabakaran Kumaresshan-6/+6
2020-08-11Switch to intra-doc links in library/std/src/os/*/fs.rsPrabakaran Kumaresshan-23/+23
2020-08-09Add RUST_STD_FREEBSD_12_ABI env variableGreg V-1/+13
Unfortunately, sanitizers do not support versioned symbols[1], so they break filesystem access via the legacy, pre-ino64 ABI. To use sanitizers on FreeBSD >= 12, we need to build the libc crate with LIBC_CI=1 to use the new ABI -- including the libc used for std. But that removes the st_lspare field std was expecting for the deprecated metadata extension. Add a way to skip that field to allow the build to work. [1]: https://github.com/google/sanitizers/issues/628
2020-07-27Hexagon libstd: update type defsBrian Cain-24/+24
2020-07-27mv std libs to library/mark-0/+4612
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 01:58:31 +0000