about summary refs log tree commit diff
path: root/library/std/src/sys
AgeCommit message (Collapse)AuthorLines
2022-12-07Avoid heap allocation when truncating thread namesGavin Li-12/+7
Ensure that heap allocation does not occur in a thread until std::thread is ready. This fixes issues with custom allocators that call std::thread::current(), since doing so prematurely initializes THREAD_INFO and causes the following thread_info::set() to fail.
2022-12-07Use more LFS functions.Michael Benfield-8/+31
On Linux, use mmap64, open64, openat64, and sendfile64 in place of their non-LFS counterparts. This is relevant to #94173. With these changes (together with rust-lang/backtrace-rs#501), the simple binaries I produce with rustc seem to have no non-LFS functions, so maybe #94173 is fixed. But I can't be sure if I've missed something and maybe some non-LFS functions could sneak in somehow.
2022-12-07Auto merge of #103459 - ChrisDenton:propagate-nulls, r=thomccbors-14/+20
Pass on null handle values to child process Fixes #101645 In Windows, stdio handles are (semantically speaking) `Option<Handle>` where `Handle` is a non-zero value. When spawning a process with `Stdio::Inherit`, Rust currently turns zero values into `-1` values. This has the unfortunate effect of breaking console subprocesses (which typically need stdio) that are spawned from gui applications (that lack stdio by default) because the console process won't be assigned handles from the newly created console (as they usually would in that situation). Worse, `-1` is actually [a valid handle](https://doc.rust-lang.org/std/os/windows/io/struct.OwnedHandle.html) which means "the current process". So if a console process, for example, waits on stdin and it has a `-1` value then the process will end up waiting on itself. This PR fixes it by propagating the nulls instead of converting them to `-1`. While I think the current behaviour is a mistake, changing it (however justified) is an API change so I think this PR should at least have some input from t-libs-api. So choosing at random... r? `@joshtriplett`
2022-12-06Don't set `STARTF_USESTDHANDLES` if none are setChris Denton-7/+15
2022-12-06Implement masking in FileType hashing on UnixArthur Carcano-1/+8
Commit 77005950f09d2f9ba54962bf5adc3f2bc3a7213f implemented masking of FileType to fix an issue[^1] in the semantic of FileType comparison. This commit introduces masking to Hash to maintain the invariant that x == y => hash(x) == hash(y). [^1]: https://github.com/rust-lang/rust/issues/104900
2022-12-05Reimplement weak! using Option.Peter Collingbourne-1/+36
2022-12-02Windows: make Command prefer non-verbatim pathsChris Denton-38/+62
When spawning Commands, the path we use can end up being queried using `env::current_exe` (or the equivalent in other languages). Not all applications handle these paths properly therefore we should have a stronger preference for non-verbatim paths when spawning processes.
2022-12-02std: cleanup timeouts in pthread condvarjoboet-66/+34
2022-12-02kmc-solid: Don't do `Box::from_raw(&*(x: Box<T>) as *const T as *mut T)`Tomoaki Kawada-18/+30
This pattern seems to be considered illegal by Miri.
2022-12-01kmc-solid: Address compiler warningsTomoaki Kawada-5/+4
Addresses the warn-by-default lints `unused_imports` and `unused_unsafe`.
2022-12-01kmc-solid: Add a stub implementation of `is_terminal`Tomoaki Kawada-0/+4
Copied from `unsupported/io.rs`. Fixes build failure.
2022-12-01kmc-solid: Use `expose_addr` and `from_exposed_addr` for pointer-integer castsTomoaki Kawada-2/+2
Pointer-integer casts are required for conversion between `EXINF` (ITRON task entry point parameter) and `*const ThreadInner`. Addresses the deny-level lint `fuzzy_provenance_casts`.
2022-12-01Auto merge of #104160 - Ayush1325:windows-args, r=m-ou-sebors-52/+2
Extract WStrUnits to sys_common::wstr This commit extracts WStrUnits from sys::windows::args to sys_common::wstr. This allows using the same structure for other targets which use wtf8 (example UEFI). This was originally a part of https://github.com/rust-lang/rust/pull/100316 Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2022-11-30Rollup merge of #104811 - haraldh:feat/wasm32_wasi_shutdown, r=joshtriplettMatthias Krüger-2/+8
feat: implement TcpStream shutdown for wasm32-wasi Signed-off-by: Harald Hoyer <harald@profian.com>
2022-11-29Add in the comment that solaris lacks also the 'linkat'Daniel Laügt-1/+1
2022-11-29hermit: Remove unused exportsMartin Kröning-3/+1
2022-11-29hermit: Fix fuzzy_provenance_castsMartin Kröning-1/+2
2022-11-28Extract WStrUnits to sys_common::wstrAyush Singh-52/+2
This commit extracts WStrUnits from sys::windows::args to sys_common::wstr. This allows using the same structure for other targets which use wtf8 (example UEFI). This was originally a part of https://github.com/rust-lang/rust/pull/100316 Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2022-11-28linkat() not available in the system headers of Solaris 10Daniel Laügt-1/+1
2022-11-26Remove redundant `all` in cfgChris Denton-6/+6
2022-11-25Implement masking in FileType comparison on UnixArthur Carcano-1/+10
Fixes: https://github.com/rust-lang/rust/issues/104900
2022-11-24feat: implement TcpStream shutdown for wasm32-wasiHarald Hoyer-2/+8
Signed-off-by: Harald Hoyer <harald@profian.com>
2022-11-22Rollup merge of #104647 - RalfJung:alloc-strict-provenance, r=thomccManish Goregaokar-0/+1
enable fuzzy_provenance_casts lint in liballoc and libstd r? ````@thomcc````
2022-11-21dont attempt strict provenance in SGXRalf Jung-0/+1
2022-11-20Rollup merge of #104558 - thomcc:unalign-diriter, r=ChrisDentonMatthias Krüger-10/+23
Don't assume `FILE_ID_BOTH_DIR_INFO` will be aligned Fixes #104530. See that issue for info. r? `@ChrisDenton`
2022-11-20cfg(miri) no longer needed in sys/unix/time.rsRalf Jung-2/+2
2022-11-18Handle the case that even the filename array is unaligned.Thom Chiovoloni-5/+14
2022-11-17Don't assume `FILE_ID_BOTH_DIR_INFO` will be alignedThom Chiovoloni-5/+9
2022-11-16available_parallelism: Handle 0 cfs_period_usAdam Casey-2/+2
There seem to be some scenarios where `cpu.cfs_period_us` can contain `0` This causes a panic when calling `std::thread::available_parallelism()` as is done so from binaries built by `cargo test`, which was how the issue was discovered. I don't feel like `0` is a good value for `cpu.cfs_period_us`, but I also don't think applications should panic if this value is seen. This case is handled by other projects which read this information: - num_cpus: https://github.com/seanmonstar/num_cpus/blob/e437b9d9083d717692e35d917de8674a7987dd06/src/linux.rs#L207-L210 - ninja: https://github.com/ninja-build/ninja/pull/2174/files - dotnet: https://github.com/dotnet/runtime/blob/c4341d45acca3ea662cd8d71e7d71094450dd045/src/coreclr/pal/src/misc/cgroup.cpp#L481-L483 Before this change, this panic could be seen in environments setup as described above: ``` $ RUST_BACKTRACE=1 cargo test Finished test [unoptimized + debuginfo] target(s) in 3.55s Running unittests src/main.rs (target/debug/deps/x-9a42e145aca2934d) thread 'main' panicked at 'attempt to divide by zero', library/std/src/sys/unix/thread.rs:546:70 stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: core::panicking::panic 3: std::sys::unix::thread::cgroups::quota 4: std::sys::unix::thread::available_parallelism 5: std::thread::available_parallelism 6: test::helpers::concurrency::get_concurrency 7: test::console::run_tests_console 8: test::test_main 9: test::test_main_static 10: x::main at ./src/main.rs:1:1 11: core::ops::function::FnOnce::call_once at /tmp/rust-1.64-1.64.0-1/library/core/src/ops/function.rs:248:5 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: test failed, to rerun pass '--bin local-rabmq-amqpprox' ``` I've tested this change in an environment which has the bad setup and rebuilding the test executable against a fixed std library fixes the panic.
2022-11-14macos, aarch64, and not(miri)Cameron-2/+2
2022-11-13just use `libc::clockid_t`Cameron-8/+3
2022-11-13Fix non-associativity of `Instant` math on `aarch64-apple-darwin` targetsJoy-3/+15
2022-11-06std: fix double-free of mutexjoboet-1/+1
2022-11-06std: remove lock wrappers in `sys_common`joboet-390/+388
2022-11-05Rollup merge of #103995 - SUPERCILEX:typos, r=Dylan-DPCDylan DPC-5/+6
Small round of typo fixes
2022-11-04Small round of typo fixesAlex Saveau-5/+6
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
2022-10-27Use stdio in UWP appsChris Denton-120/+28
This has been supported since Windows 10.0.16299. See https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-core-console-l1-1-0dll
2022-10-27Rollup merge of #103564 - RalfJung:miri-unused, r=thomccMatthias Krüger-2/+3
library: allow some unused things in Miri Should help for https://github.com/rust-lang/rust/pull/102950.
2022-10-26thread::set_name: debug-assert that things went wellRalf Jung-6/+10
2022-10-26library: allow some unused things in MiriRalf Jung-2/+3
2022-10-25Rollup merge of #103379 - cuviper:truncate-thread-name, r=thomccDylan DPC-0/+18
Truncate thread names on Linux and Apple targets These targets have system limits on the thread names, 16 and 64 bytes respectively, and `pthread_setname_np` returns an error if the name is longer. However, we're not in a context that can propagate errors when we call this, and we used to implicitly truncate on Linux with `prctl`, so now we manually truncate these names ahead of time. r? ``````@thomcc``````
2022-10-24Rollup merge of #102766 - thomcc:remove-resolv, r=Mark-SimulacrumYuki Okushi-4/+0
Don't link to `libresolv` in libstd on Darwin Currently we link `libresolv` into every Rust program on apple targets despite never using it (as of https://github.com/rust-lang/rust/pull/44965). I had thought we needed this for `getaddrinfo` or something, but we do not / cannot safely use it. I'd like to fix this for `libiconv` too (the other library we pull in. that's harder since it's coming in through `libc`, which is https://github.com/rust-lang/libc/pull/2944)). --- This may warrant release notes. I'm not sure but I've added the flag regardless -- It's a change to the list of dylibs every Rust program pulls in, so it's worth mentioning. It's pretty unlikely anybody was relying on this being pulled in, and `std` does not guarantee that it will link (and thus transitively provide access to) any particular system library -- anybody relying on that behavior would already be broken when dynamically linking std. That is, there's an outside chance something will fail to link on macOS and iOS because it was accidentally relying on our unnecessary dependency. (If that *does* happen, that project could be easily fixed by linking libresolv explicitly on those platforms, probably via `#[link(name = "resolv")] extern {}`,` -Crustc-link-lib=resolv`, `println!("cargo:rustc-link-lib=resolv")`, or one of several places in `.config/cargo.toml`) --- I'm also going to preemptively add the nomination for discussing this in the libs meeting. Basically: Do we care about programs that assume we will bring libraries in that we do not use. `libresolv` and `libiconv` on macOS/iOS are in this camp (`libresolv` because we used to use it, and `libiconv` because the `libc` crate was unintentionally(?) pulling it in to every Rust program). I'd like to remove them both, but this may cause link issues programs that are relying on `std` to depend on them transitively. (Relying on std for this does not work in all build configurations, so this seems very fragile, and like a use case we should not support). More generally, IMO we should not guarantee the specific set of system-provided libraries we use (beyond what is implied by an OS version requirement), which means we'd be free to remove this cruft.
2022-10-24Pass on null handle values to child processChris Denton-7/+5
2022-10-23Rollup merge of #103005 - solid-rs:patch/kmc-solid/readdir-terminator, r=m-ou-seMichael Howell-8/+12
kmc-solid: Handle errors returned by `SOLID_FS_ReadDir` Fixes the issue where the `std::fs::ReadDir` implementaton of the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets silently suppressed errors returned by the underlying `SOLID_FS_ReadDir` system function. The new implementation correctly handles all cases: - `SOLID_ERR_NOTFOUND` indicates the end of directory stream. - `SOLID_ERR_OK` + non-empty `d_name` indicates success. - Some old filesystem drivers may return `SOLID_ERR_OK` + empty `d_name` to indicate the end of directory stream. - Any other negative values (per ITRON convention) represent an error.
2022-10-23Auto merge of #103137 - dtolnay:readdir, r=Mark-Simulacrumbors-20/+65
Eliminate 280-byte memset from ReadDir iterator This guy: https://github.com/rust-lang/rust/blob/1536ab1b383f21b38f8d49230a2aecc51daffa3d/library/std/src/sys/unix/fs.rs#L589 It turns out `libc::dirent64` is quite big&mdash;https://docs.rs/libc/0.2.135/libc/struct.dirent64.html. In #103135 this memset accounted for 0.9% of the runtime of iterating a big directory. Almost none of the big zeroed value is ever used. We memcpy a tiny prefix (19 bytes) into it, and then read just 9 bytes (`d_ino` and `d_type`) back out. We can read exactly those 9 bytes we need directly from the original entry_ptr instead. ## History This code got added in #93459 and tweaked in #94272 and #94750. Prior to #93459, there was no memset but a full 280 bytes were being copied from the entry_ptr. <table><tr><td>copy 280 bytes</td></tr></table> This was not legal because not all of those bytes might be initialized, or even allocated, depending on the length of the directory entry's name, leading to a segfault. That PR fixed the segfault by creating a new zeroed dirent64 and copying just the guaranteed initialized prefix into it. <table><tr><td>memset 280 bytes</td><td>copy 19 bytes</td></tr></table> However this was still buggy because it used `addr_of!((*entry_ptr).d_name)`, which is considered UB by Miri in the case that the full extent of entry_ptr is not in bounds of the same allocation. (Arguably this shouldn't be a requirement, but here we are.) The UB got fixed by #94272 by replacing `addr_of` with some pointer manipulation based on `offset_from`, but still fundamentally the same operation. <table><tr><td>memset 280 bytes</td><td>copy 19 bytes</td></tr></table> Then #94750 noticed that only 9 of those 19 bytes were even being used, so we could pick out only those 9 to put in the ReadDir value. <table><tr><td>memset 280 bytes</td><td>copy 19 bytes</td><td>copy 9 bytes</td></tr></table> After my PR we just grab the 9 needed bytes directly from entry_ptr. <table><tr><td>copy 9 bytes</td></tr></table> The resulting code is more complex but I believe still worthwhile to land for the following reason. This is an extremely straightforward thing to accomplish in C and clearly libc assumes that; literally just `entry_ptr->d_name`. The extra work in comparison to accomplish it in Rust is not an example of any actual safety being provided by Rust. I believe it's useful to have uncovered that and think about what could be done in the standard library or language to support this obvious operation better. ## References - https://man7.org/linux/man-pages/man3/readdir.3.html
2022-10-22Rollup merge of #103360 - ChrisDenton:isterm-filetype, r=thomccDylan DPC-2/+12
Reduce false positives in msys2 detection Currently msys2 will be detected by getting the file path and looking to see if it contains the substrings "msys-" and "-ptr" (or "cygwin-" and "-pty"). This risks false positives, especially with filesystem files and if `GetFileInformationByHandleEx` returns a [full path](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntqueryinformationfile#remarks). This PR adds a check to see if the handle is a pipe before doing the substring search. Additionally, for "msys2-" or "cygwin-" it only checks if the file name starts with the substring rather than looking at the whole path.
2022-10-21Move truncation next to other thread tests for tidyJosh Stone-25/+0
2022-10-21Truncate thread names on Linux and Apple targetsJosh Stone-0/+43
These targets have system limits on the thread names, 16 and 64 bytes respectively, and `pthread_setname_np` returns an error if the name is longer. However, we're not in a context that can propagate errors when we call this, and we used to implicitly truncate on Linux with `prctl`, so now we manually truncate these names ahead of time.
2022-10-21Reduce false positives in msys2 detectionChris Denton-2/+12
This checks that: * the handle is a pipe * the pipe's file name starts with "msys-" or "cygwin-" rather than looking in the full path.
2022-10-20Change process spawning to inherit the parent's signal mask by defaultRain-70/+121
Previously, the signal mask is always reset when a child process is started. This breaks tools like `nohup` which expect `SIGHUP` to be blocked. With this change, the default behavior changes to inherit the signal mask. This also changes the signal disposition for `SIGPIPE` to only be changed if the `#[unix_sigpipe]` attribute isn't set.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-12 05:02:03 +0000