about summary refs log tree commit diff
path: root/library/std/src/sys
AgeCommit message (Collapse)AuthorLines
2021-01-13unix ExitStatus: Provide .core_dumpedIan Jackson-0/+12
This is essential for proper reporting of child process status on Unix. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-01-13unix ExitStatus: Provide .into_raw()Ian Jackson-0/+12
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-01-13unix ExitStatus: Clarify docs for .signal()Ian Jackson-0/+2
We need to be clear that this never returns WSTOPSIG. That is, if WIFSTOPPED, the return value is None. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-01-13unix ExitStatus: Do not treat WIFSTOPPED as WIFSIGNALEDIan Jackson-1/+1
A unix wait status can contain, at least, exit statuses, termination signals, and stop signals. WTERMSIG is only valid if WIFSIGNALED. https://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html It will not be easy to experience this bug with `Command`, because that doesn't pass WUNTRACED. But you could make an ExitStatus containing, say, a WIFSTOPPED, from a call to one of the libc wait functions. (In the WIFSTOPPED case, there is WSTOPSIG. But a stop signal is encoded differently to a termination signal, so WTERMSIG and WSTOPSIG are by no means the same.) Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-01-13Update code to account for extern ABI requirementMark Rousskov-1/+1
2021-01-13deprecate atomic::spin_loop_hint in favour of hint::spin_loopAshley Mannix-4/+6
2020-12-29Fix small typo in time commentBlackHoleFox-1/+1
2020-12-22Update library/std/src/sys/windows/thread_parker.rsLinus Färnstrand-1/+1
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2020-12-22Fix compare_and_swap in Windows thread_parkerLinus Färnstrand-1/+1
2020-12-22Migrate standard library away from compare_and_swapLinus Färnstrand-8/+8
2020-12-21Auto merge of #80088 - operutka:fix-cmsg-len-uclibc, r=dtolnaybors-1/+5
Fix failing build of std on armv5te-unknown-linux-uclibceabi due to missing cmsg_len_zero I'm getting the following error when trying to build `std` on `armv5te-unknown-linux-uclibceabi`: ``` error[E0425]: cannot find value `cmsg_len_zero` in this scope --> /home/operutka/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/ext/net/ancillary.rs:376:47 | 376 | let data_len = (*cmsg).cmsg_len - cmsg_len_zero; | ^^^^^^^^^^^^^ not found in this scope ``` Obviously, this branch: ```rust cfg_if::cfg_if! { if #[cfg(any(target_os = "android", all(target_os = "linux", target_env = "gnu")))] { let cmsg_len_zero = libc::CMSG_LEN(0) as libc::size_t; } else if #[cfg(any( target_os = "dragonfly", target_os = "emscripten", target_os = "freebsd", all(target_os = "linux", target_env = "musl",), target_os = "netbsd", target_os = "openbsd", ))] { let cmsg_len_zero = libc::CMSG_LEN(0) as libc::socklen_t; } } ``` does not cover the case `all(target_os = "linux", target_env = "uclibc")`.
2020-12-20Auto merge of #74699 - notriddle:fd-non-negative, r=m-ou-sebors-2/+9
Mark `-1` as an available niche for file descriptors Based on discussion from <https://internals.rust-lang.org/t/can-the-standard-library-shrink-option-file/12768>, the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen, particularly on Linux, but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the "upper" bound, which is actually -1, to be expressed in two's complement.
2020-12-20Check that c_int is i32 in FileDesc::new.Mara Bos-1/+1
2020-12-16Fix failing build of std on armv5te-unknown-linux-uclibceabi due to missing ↵Ondrej Perutka-1/+5
cmsg_len_zero
2020-12-16Auto merge of #78833 - CDirkx:parse_prefix, r=dtolnaybors-78/+135
Refactor and fix `parse_prefix` on Windows This PR is an extension of #78692 as well as a general refactor of `parse_prefix`: **Fixes**: There are two errors in the current implementation of `parse_prefix`: Firstly, in the current implementation only `\` is recognized as a separator character in device namespace prefixes. This behavior is only correct for verbatim paths; `"\\.\C:/foo"` should be parsed as `"C:"` instead of `"C:/foo"`. Secondly, the current implementation only handles single separator characters. In non-verbatim paths a series of separator characters should be recognized as a single boundary, e.g. the UNC path `"\\localhost\\\\\\C$\foo"` should be parsed as `"\\localhost\\\\\\C$"` and then `UNC(server: "localhost", share: "C$")`, but currently it is not parsed at all, because it starts being parsed as `\\localhost\` and then has an invalid empty share location. Paths like `"\\.\C:/foo"` and `"\\localhost\\\\\\C$\foo"` are valid on Windows, they are equivalent to just `"C:\foo"`. **Refactoring**: All uses of `&[u8]` within `parse_prefix` are extracted to helper functions and`&OsStr` is used instead. This reduces the number of places unsafe is used: - `get_first_two_components` is adapted to the more general `parse_next_component` and used in more places - code for parsing drive prefixes is extracted to `parse_drive`
2020-12-14Auto merge of #77618 - fusion-engineering-forks:windows-parker, r=Amanieubors-0/+299
Add fast futex-based thread parker for Windows. This adds a fast futex-based thread parker for Windows. It either uses WaitOnAddress+WakeByAddressSingle or NT Keyed Events (NtWaitForKeyedEvent+NtReleaseKeyedEvent), depending on which is available. Together, this makes this thread parker work for Windows XP and up. Before this change, park()/unpark() did not work on Windows XP: it needs condition variables, which only exist since Windows Vista. --- Unfortunately, NT Keyed Events are an undocumented Windows API. However: - This API is relatively simple with obvious behaviour, and there are several (unofficial) articles documenting the details. [1] - parking_lot has been using this API for years (on Windows versions before Windows 8). [2] Many big projects extensively use parking_lot, such as servo and the Rust compiler itself. - It is the underlying API used by Windows SRW locks and Windows critical sections. [3] [4] - The source code of the implementations of Wine, ReactOs, and Windows XP are available and match the expected behaviour. - The main risk with an undocumented API is that it might change in the future. But since we only use it for older versions of Windows, that's not a problem. - Even if these functions do not block or wake as we expect (which is unlikely, see all previous points), this implementation would still be memory safe. The NT Keyed Events API is only used to sleep/block in the right place. [1]\: http://www.locklessinc.com/articles/keyed_events/ [2]\: https://github.com/Amanieu/parking_lot/commit/43abbc964e [3]\: https://docs.microsoft.com/en-us/archive/msdn-magazine/2012/november/windows-with-c-the-evolution-of-synchronization-in-windows-and-c [4]\: Windows Internals, Part 1, ISBN 9780735671300 --- The choice of fallback API is inspired by parking_lot(_core), but the implementation of this thread parker is different. While parking_lot has no use for a fast path (park() directly returning if unpark() was already called), this implementation has a fast path that returns without even checking which waiting/waking API to use, as the same atomic variable with compatible states is used in all cases.
2020-12-11Auto merge of #79893 - RalfJung:forget-windows, r=oli-obkbors-7/+4
Windows TLS: ManuallyDrop instead of mem::forget The Windows TLS implementation still used `mem::forget` instead of `ManuallyDrop`, leading to the usual problem of "using" the `Box` when it should not be used any more.
2020-12-10Rollup merge of #79375 - vext01:kernel-copy-temps, r=bjorn3Tyler Mandry-8/+11
Make the kernel_copy tests more robust/concurrent. These tests write to the same filenames in /tmp and in some cases these files don't get cleaned up properly. This caused issues for us when different users run the tests on the same system, e.g.: ``` ---- sys::unix::kernel_copy::tests::bench_file_to_file_copy stdout ---- thread 'sys::unix::kernel_copy::tests::bench_file_to_file_copy' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', library/std/src/sys/unix/kernel_copy/tests.rs:71:10 ---- sys::unix::kernel_copy::tests::bench_file_to_socket_copy stdout ---- thread 'sys::unix::kernel_copy::tests::bench_file_to_socket_copy' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', library/std/src/sys/unix/kernel_copy/tests.rs💯10 ``` Use `std::sys_common::io__test::tmpdir()` to solve this. CC ``@the8472.``
2020-12-10Fix fd test caseMichael Howell-1/+1
2020-12-10Add safety note to library/std/src/sys/unix/fd.rsMichael Howell-0/+1
Co-authored-by: Elichai Turkel <elichai.turkel@gmail.com>
2020-12-10Mark `-1` as an available niche for file descriptorsMichael Howell-1/+7
Based on discussion from https://internals.rust-lang.org/t/can-the-standard-library-shrink-option-file/12768, the file descriptor -1 is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen, particularly on Linux, but would not necessarily be portable. This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the "upper" bound, which is actually -1, to be expressed in two's complement.
2020-12-10Windows TLS: ManuallyDrop instead of mem::forgetRalf Jung-7/+4
2020-12-10Auto merge of #79274 - the8472:probe-eperm, r=nagisabors-36/+50
implement better availability probing for copy_file_range Followup to https://github.com/rust-lang/rust/pull/75428#discussion_r469616547 Previously syscall detection was overly pessimistic. Any attempt to copy to an immutable file (EPERM) would disable copy_file_range support for the whole process. The change tries to copy_file_range on invalid file descriptors which will never run into the immutable file case and thus we can clearly distinguish syscall availability.
2020-12-09Improve comment grammarThe8472-2/+2
2020-12-09implement better availability probing for copy_file_rangeThe8472-34/+48
previously any attempt to copy to an immutable file (EPERM) would disable copy_file_range support for the whole process.
2020-12-09Auto merge of #77611 - oli-obk:atomic_miri_leakage, r=nagisabors-13/+0
Directly use raw pointers in `AtomicPtr` store/load I was unable to find any reason for this limitation in the latest source of LLVM or in the documentation [here](http://llvm.org/docs/Atomics.html#libcalls-atomic). fixes https://github.com/rust-lang/miri/issues/1574
2020-12-09Auto merge of #79387 - woodruffw-forks:ww/peer-cred-pid-macos, r=Amanieubors-15/+57
ext/ucred: Support PID in peer creds on macOS This is a follow-up to https://github.com/rust-lang/rust/pull/75148 (RFC: https://github.com/rust-lang/rust/issues/42839). The original PR used `getpeereid` on macOS and the BSDs, since they don't (generally) support the `SO_PEERCRED` mechanism that Linux supplies. This PR splits the macOS/iOS implementation of `peer_cred()` from that of the BSDs, since macOS supplies the `LOCAL_PEERPID` sockopt as a source of the missing PID. It also adds a `cfg`-gated tests that ensures that platforms with support for PIDs in `UCred` have the expected data.
2020-12-03Make the kernel_copy tests more robust/concurrent.Edd Barrett-8/+11
These tests write to the same filenames in /tmp and in some cases these files don't get cleaned up properly. This caused issues for us when different users run the tests on the same system, e.g.: ``` ---- sys::unix::kernel_copy::tests::bench_file_to_file_copy stdout ---- thread 'sys::unix::kernel_copy::tests::bench_file_to_file_copy' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', library/std/src/sys/unix/kernel_copy/tests.rs:71:10 ---- sys::unix::kernel_copy::tests::bench_file_to_socket_copy stdout ---- thread 'sys::unix::kernel_copy::tests::bench_file_to_socket_copy' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', library/std/src/sys/unix/kernel_copy/tests.rs:100:10 ``` Use `std::sys_common::io__test::tmpdir()` to solve this.
2020-12-03fix copy specialization not updating Take wrappersThe8472-14/+45
2020-12-02update test to check Take limits after copyingThe8472-2/+9
2020-12-02Auto merge of #69864 - LinkTed:master, r=Amanieubors-1771/+3097
unix: Extend UnixStream and UnixDatagram to send and receive file descriptors Add the functions `recv_vectored_fds` and `send_vectored_fds` to `UnixDatagram` and `UnixStream`. With this functions `UnixDatagram` and `UnixStream` can send and receive file descriptors, by using `recvmsg` and `sendmsg` system call.
2020-12-01Leverage kernel copy for UnixStreamNicolas Koch-0/+29
UDS can be a sendfile destination, just like TCP sockets.
2020-12-01Add benchmark for File to UnixStream copyNicolas Koch-0/+29
2020-11-28Remove now-unnecessary `miri_static_root` invocationoli-13/+0
2020-11-26Add comment for the previous android bug fixLinkTed-0/+4
2020-11-24Bug fix for android platform, because of the wrong behavior of CMSG_NXTHDRLinkTed-0/+19
2020-11-24ext/ucred: fmt checkWilliam Woodruff-26/+8
2020-11-24ext/ucred: Support PID in peer creds on macOSWilliam Woodruff-5/+65
2020-11-24Auto merge of #78953 - mzohreva:mz/from_raw_fd, r=Mark-Simulacrumbors-10/+35
Add Metadata in std::os::fortanix_sgx::io::FromRawFd Needed for https://github.com/fortanix/rust-sgx/pull/291 cc `@jethrogb`
2020-11-22Drop support for cloudabi targetsLzu Tao-4924/+4
2020-11-20Auto merge of #79205 - rust-lang:jdm-patch-1, r=m-ou-sebors-0/+1
Extend meta parameters to all generated code in compat_fn. Fixes https://github.com/rust-lang/rust/issues/79203. This addresses a regression from 7e2032390cf34f3ffa726b7bd890141e2684ba63 for UWP targets.
2020-11-20Auto merge of #79196 - RalfJung:syscall, r=m-ou-sebors-1/+1
unix/weak: pass arguments to syscall at the given type Given that we know the type the argument should have, it seems a bit strange not to use that information. r? `@m-ou-se` `@cuviper`
2020-11-20unix/weak: pass arguments to syscall at the given typeRalf Jung-1/+1
2020-11-19Auto merge of #79060 - dtolnay:symlinkarg, r=Mark-Simulacrumbors-49/+54
Disambiguate symlink argument names The current argument naming in the following standard library functions is horribly ambiguous. - std::os::unix::fs::symlink: https://doc.rust-lang.org/1.47.0/std/os/unix/fs/fn.symlink.html - std::os::windows::fs::symlink_file: https://doc.rust-lang.org/1.47.0/std/os/windows/fs/fn.symlink_file.html - std::os::windows::fs::symlink_dir: https://doc.rust-lang.org/1.47.0/std/os/windows/fs/fn.symlink_dir.html **Notice that Swift uses one of the same names we do (`dst`) to refer to the opposite thing.** <br> | | the&nbsp;one&nbsp;that&nbsp;exists | the&nbsp;one&nbsp;that&nbsp;is<br>being&nbsp;created | reference | | --- | --- | --- | --- | | Rust | `src` | `dst` | | | Swift | `withDestinationPath`<br>`destPath` | `atPath`<br>`path` | <sub>https://developer.apple.com/documentation/foundation/filemanager/1411007-createsymboliclink</sub> | | D | `original` | `link` | <sub>https://dlang.org/library/std/file/symlink.html</sub> | | Go | `oldname` | `newname` | <sub>https://golang.org/pkg/os/#Symlink</sub> | | C++| `target` | `link` | <sub>https://en.cppreference.com/w/cpp/filesystem/create_symlink</sub> | | POSIX | `path1` | `path2` | <sub>https://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html</sub> | | Linux | `target` | `linkpath` | <sub>https://man7.org/linux/man-pages/man2/symlink.2.html</sub> | Out of these I happen to like D's argument names and am proposing that we adopt them.
2020-11-19Extend meta parameters to all generated code in compat_fn.Josh Matthews-0/+1
2020-11-18Rollup merge of #79039 - thomcc:weakly-relaxing, r=AmanieuMara Bos-6/+40
Tighten the bounds on atomic Ordering in std::sys::unix::weak::Weak This moves reading this from multiple SeqCst reads to Relaxed read + Acquire fence if we are actually going to use the data. Would love to avoid the Acquire fence, but doing so would need Ordering::Consume, which neither Rust, nor LLVM supports (a shame, since this fence is hardly free on ARM, which is what I was hoping to improve). r? ``@Amanieu`` (Sorry for always picking you, but I know a lot of people wouldn't feel comfortable reviewing atomic ordering changes)
2020-11-18Rollup merge of #78785 - cuviper:weak-getrandom, r=m-ou-seMara Bos-18/+35
linux: try to use libc getrandom to allow interposition We'll try to use a weak `getrandom` symbol first, because that allows things like `LD_PRELOAD` interposition. For example, perf measurements might want to disable randomness to get reproducible results. If the weak symbol is not found, we fall back to a raw `SYS_getrandom` call.
2020-11-17Auto merge of #79128 - m-ou-se:rollup-lzz1dym, r=m-ou-sebors-2/+58
Rollup of 9 pull requests Successful merges: - #77939 (Ensure that the source code display is working with DOS backline) - #78138 (Upgrade dlmalloc to version 0.2) - #78967 (Make codegen tests compatible with extra inlining) - #79027 (Limit storage duration of inlined always live locals) - #79077 (document that __rust_alloc is also magic to our LLVM fork) - #79088 (clarify `span_label` documentation) - #79097 (Code block invalid html tag lint) - #79105 (std: Fix test `symlink_hard_link` on Windows) - #79107 (build-manifest: strip newline from rustc version) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2020-11-17Rollup merge of #78138 - fortanix:raoul/dlmalloc0.2, r=Mark-SimulacrumMara Bos-2/+58
Upgrade dlmalloc to version 0.2 In preparation of adding dynamic memory management support for SGXv2-enabled platforms, the dlmalloc crate has been refactored. More specifically, support has been added to implement platform specification outside of the dlmalloc crate. (see https://github.com/alexcrichton/dlmalloc-rs/pull/15) This PR upgrades dlmalloc to version 0.2 for the `wasm` and `sgx` targets. As the dlmalloc changes have received a positive review, but have not been merged yet, this PR contains a commit to prevent tidy from aborting CI prematurely. cc: `@jethrogb`
2020-11-17Auto merge of #78924 - bjorn3:less_sysroot_build_scripts, r=Mark-Simulacrumbors-0/+71
Make the libstd build script smaller Of all sysroot crates currently only compiler_builtins, miniz_oxide and std require a build script. compiler_builtins uses to conditionally enable certain features and possibly compile a C version ([source](https://github.com/rust-lang/compiler-builtins/blob/63ccaf11f08fb5d0b39cc33884c5a1a63f547ace/build.rs)), miniz_oxide only uses it to detect if liballoc is supported as the MSRV is 1.34.0 instead of the 1.36.0 which stabilized liballoc ([source](https://github.com/Frommi/miniz_oxide/blob/28514ec09f0b1ce74bfb2d561de52a6652ce377a/miniz_oxide/build.rs)). std now only uses it to enable `freebsd12` when the `RUST_STD_FREEBSD_12_ABI` env var is set, to determine if `restricted-std` should be set, to set the `STD_ENV_ARCH` env var identical to `CARGO_CFG_TARGET_ARCH`, and to unconditionally enable `backtrace_in_libstd`. If all build scripts were to be removed, it would be possible for rustc to completely compile it's own sysroot. It currently requires a rustc version that already has an available libstd to compile the build scripts. If rustc can completely compile it's own sysroot, rustbuild could be simplified to not forcefully use the bootstrap compiler for build scripts. `@rustbot` modify labels: +T-compiler +libs-impl
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-02 06:30:30 +0000