summary refs log tree commit diff
path: root/library/std/src/sys
AgeCommit message (Collapse)AuthorLines
2021-10-01Call `libc::sigaction()` only on AndroidFabian Wolff-3/+14
2021-10-01Fix ctrl-c causing reads of stdin to return empty on Windows.Arlo Siemsen-9/+19
Fixes #89177
2021-09-30Rollup merge of #89306 - devnexen:haiku_ncpus, r=nagisaManish Goregaokar-1/+10
thread: implements available_concurrency on haiku
2021-09-29Auto merge of #89011 - bjorn3:restructure_rt, r=dtolnaybors-1/+1
Restructure std::rt These changes should reduce binary size slightly while at the same slightly improving performance of startup, thread spawning and `std::thread::current()`. I haven't verified if the compiler is able to optimize some of these cases already, but at least for some others the compiler is unable to do these optimizations as they slightly change behavior in cases where program startup would crash anyway by omitting a backtrace and panic location. I can remove 6f6bb16 if preferred.
2021-09-28Clean up unneeded explicit pointer castDavid Tolnay-1/+1
The reference automatically coerces to a pointer. Writing an explicit cast here is slightly misleading because that's most commonly used when a pointer needs to be converted from one pointer type to another, e.g. `*const c_void` to `*const sigaction` or vice versa.
2021-09-28Rename `std::thread::available_onccurrency` to ↵Yoshua Wuyts-7/+7
`std::thread::available_parallelism`
2021-09-28Add SOLID targetsTomoaki Kawada-0/+3740
SOLID[1] is an embedded development platform provided by Kyoto Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support for SOLID. # New Targets The following targets are added: - `aarch64-kmc-solid_asp3` - `armv7a-kmc-solid_asp3-eabi` - `armv7a-kmc-solid_asp3-eabihf` SOLID's target software system can be divided into two parts: an RTOS kernel, which is responsible for threading and synchronization, and Core Services, which provides filesystems, networking, and other things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems (more precisely, systems where only one processor core is allocated for SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is traditionally only specified at the source-code level, the ABI is unique to each implementation, which is why `asp3` is included in the target names. More targets could be added later, as we support other base kernels (there are at least three at the point of writing) and are interested in supporting other processor architectures in the future. # C Compiler Although SOLID provides its own supported C/C++ build toolchain, GNU Arm Embedded Toolchain seems to work for the purpose of building Rust. # Unresolved Questions A μITRON4 kernel can support `Thread::unpark` natively, but it's not used by this commit's implementation because the underlying kernel feature is also used to implement `Condvar`, and it's unclear whether `std` should guarantee that parking tokens are not clobbered by other synchronization primitives. # Unsupported or Unimplemented Features Most features are implemented. The following features are not implemented due to the lack of native support: - `fs::File::{file_attr, truncate, duplicate, set_permissions}` - `fs::{symlink, link, canonicalize}` - Process creation - Command-line arguments Backtrace generation is not really a good fit for embedded targets, so it's intentionally left unimplemented. Unwinding is functional, however. ## Dynamic Linking Dynamic linking is not supported. The target platform supports dynamic linking, but enabling this in Rust causes several problems. - The linker invocation used to build the shared object of `std` is too long for the platform-provided linker to handle. - A linker script with specific requirements is required for the compiled shared object to be actually loadable. As such, we decided to disable dynamic linking for now. Regardless, the users can try to create shared objects by manually invoking the linker. ## Executable Building an executable is not supported as the notion of "executable files" isn't well-defined for these targets. [1] https://solid.kmckk.com/SOLID/ [2] http://ertl.jp/ITRON/SPEC/mitron4-e.html [3] https://en.wikipedia.org/wiki/ITRON_project [4] https://toppers.jp/
2021-09-27thread: implements available_concurrency on haikuDavid Carlier-1/+10
2021-09-23Auto merge of #88587 - bdbai:fix/uwpio, r=joshtriplettbors-4/+7
Fix WinUWP std compilation errors due to I/O safety I/O safety for Windows has landed in #87329. However, it does not cover UWP specific parts and prevents all UWP targets from building. See https://github.com/YtFlow/Maple/issues/18. This PR fixes these compile errors when building std for UWP targets.
2021-09-23Reason safety for unsafe blocks for uwp stdinbdbai-0/+2
2021-09-16Replace a couple of asserts with rtassert! in rt codebjorn3-1/+1
This replaces a couple of panic locations with hard aborts. The panics can't be catched by the user anyway in these locations.
2021-09-14Add chown functions to std::os::unix::fs to change the owner and group of filesJosh Triplett-0/+17
This is a straightforward wrapper that uses the existing helpers for C string handling and errno handling. Having this available is convenient for UNIX utility programs written in Rust, and avoids having to call unsafe functions like `libc::chown` directly and handle errors manually, in a program that may otherwise be entirely safe code. In addition, these functions provide a more Rustic interface by accepting appropriate traits and using `None` rather than `-1`.
2021-09-10Use `libc::sigaction()` instead of `sys::signal()` to prevent a deadlockFabian Wolff-4/+3
2021-09-09Fix more Windows compilation errors.Dan Gohman-15/+6
2021-09-09Fix Windows compilation errors.Dan Gohman-2/+2
2021-09-09Add a `try_clone()` function to `OwnedFd`.Dan Gohman-76/+5
As suggested in #88564. This adds a `try_clone()` to `OwnedFd` by refactoring the code out of the existing `File`/`Socket` code.
2021-09-04linux/aarch64 Now() should be actually_monotonic()Ali Saidi-0/+1
While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (#49281, #56940) which cause time to not monotonically increase, these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3e183 std: Force `Instant::now()` to be monotonic added a mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this, but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance.
2021-09-02Auto merge of #87580 - ChrisDenton:win-arg-parse-2008, r=m-ou-sebors-123/+200
Update Windows Argument Parsing Fixes #44650 The Windows command line is passed to applications [as a single string](https://docs.microsoft.com/en-us/archive/blogs/larryosterman/the-windows-command-line-is-just-a-string) which the application then parses to get a list of arguments. The standard rules (as used by C/C++) for parsing the command line have slightly changed over the years, most recently in 2008 which added new escaping rules. This PR implements the new rules as [described on MSDN](https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=msvc-160#parsing-c-command-line-arguments) and [further detailed here](https://daviddeley.com/autohotkey/parameters/parameters.htm#WIN). It has been tested against the behaviour of C++ by calling a C++ program that outputs its raw command line and the contents of `argv`. See [my repo](https://github.com/ChrisDenton/winarg/tree/std) if anyone wants to reproduce my work. For an overview of how this PR changes argument parsing behavior and why we feel it is warranted see https://github.com/rust-lang/rust/pull/87580#issuecomment-893833893. For some examples see: https://github.com/rust-lang/rust/pull/87580#issuecomment-894299249
2021-09-02I/O safety for WinUWPbdbai-4/+5
2021-09-02Auto merge of #83342 - Count-Count:win-console-incomplete-utf8, r=m-ou-sebors-14/+90
Allow writing of incomplete UTF-8 sequences to the Windows console via stdout/stderr # Problem Writes of just an incomplete UTF-8 byte sequence (e.g. `b"\xC3"` or `b"\xF0\x9F"`) to stdout/stderr with a Windows console attached error with `io::ErrorKind::InvalidData, "Windows stdio in console mode does not support writing non-UTF-8 byte sequences"` even though further writes could complete the codepoint. This is currently a rare occurence since the [linewritershim](https://github.com/rust-lang/rust/blob/2c56ea38b045624dc8b42ec948fc169eaff1206a/library/std/src/io/buffered/linewritershim.rs) implementation flushes complete lines immediately and buffers up to 1024 bytes for incomplete lines. It can still happen as described in #83258. The problem will become more pronounced once the developer can switch stdout/stderr from line-buffered to block-buffered or immediate when the changes in the "Switchable buffering for Stdout" pull request (#78515) get merged. # Patch description If there is at least one valid UTF-8 codepoint all valid UTF-8 is passed through to the extracted `write_valid_utf8_to_console()` fn. The new code only comes into play if `write()` is being passed a short byte slice comprising an incomplete UTF-8 codepoint. In this case up to three bytes are buffered in the `IncompleteUtf8` struct associated with `Stdout` / `Stderr`. The bytes are accepted one at a time. As soon as an error can be detected `io::ErrorKind::InvalidData, "Windows stdio in console mode does not support writing non-UTF-8 byte sequences"` is returned. Once a complete UTF-8 codepoint is received it is passed to the `write_valid_utf8_to_console()` and the buffer length is set to zero. Calling `flush()` will neither error nor write anything if an incomplete codepoint is present in the buffer. # Tests Currently there are no Windows-specific tests for console writing code at all. Writing (regression) tests for this problem is a bit challenging since unit tests and UI tests don't run in a console and suddenly popping up another console window might be surprising to developers running the testsuite and it might not work at all in CI builds. To just test the new functionality in unit tests the code would need to be refactored. Some guidance on how to proceed would be appreciated. # Public API changes * `std::str::verifications::utf8_char_width()` would be exposed as `std::str::utf8_char_width()` behind the "str_internals" feature gate. # Related issues * Fixes #83258. * PR #78515 will exacerbate the problem. # Open questions * Add tests? * Squash into one commit with better commit message?
2021-09-01Rollup merge of #88542 - tavianator:readdir_r-errno, r=jyn514Mara Bos-2/+3
Use the return value of readdir_r() instead of errno POSIX says: > If successful, the readdir_r() function shall return zero; otherwise, > an error number shall be returned to indicate the error. But we were previously using errno instead of the return value. This led to issue #86649.
2021-08-31Use the return value of readdir_r() instead of errnoTavian Barnes-2/+3
POSIX says: > If successful, the readdir_r() function shall return zero; otherwise, > an error number shall be returned to indicate the error. But we were previously using errno instead of the return value. This led to issue #86649.
2021-08-30clean up `c::linger` conversionibraheemdev-2/+2
2021-08-30add `TcpStream::set_linger` and `TcpStream::linger`ibraheemdev-1/+95
2021-08-27Handle stack_t.ss_sp type change for DragonFlyBSDRyan Zoeller-14/+0
stack_t.ss_sp is now c_void on DragonFlyBSD, so the specialization is no longer needed. Changed in https://github.com/rust-lang/libc/commit/02922ef7504906589d02c2e4d97d1172fa247cc3.
2021-08-24Manual Debug for Unix ExitCode ExitStatus ExitStatusErrorIan Jackson-3/+21
These structs have misleading names. An ExitStatus[Error] is actually a Unix wait status; an ExitCode is actually an exit status. The Display impls are fixed, but the Debug impls are still misleading, as reported in #74832. Fix this by pretending that these internal structs are called `unix_exit_status` and `unix_wait_status` as applicable. (We can't actually rename the structs because of the way that the cross-platform machinery works: the names are cross-platform.) Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-08-24Remove unnecessary unsafe block in `process_unix`Léo Lanteri Thauvin-2/+1
2021-08-22Fix typos “an”→“a” and a few different ones that appeared in the ↵Frank Steffahn-1/+1
same search
2021-08-19Factor out a common `RawFd`/`AsRawFd`/etc for Unix and WASI.Dan Gohman-35/+69
2021-08-19Use the correct `into_*` on Windows to avoid dropping a stdio handle.Dan Gohman-2/+2
Use `into_raw_handle()` rather than `into_inner()` to completely consume a `Handle` without dropping its contained handle.
2021-08-19Fix an unused import warning.Dan Gohman-1/+1
2021-08-19Update PidFd for the new I/O safety APIs.Dan Gohman-5/+11
2021-08-19I/O safety.Dan Gohman-377/+771
Introduce `OwnedFd` and `BorrowedFd`, and the `AsFd` trait, and implementations of `AsFd`, `From<OwnedFd>` and `From<T> for OwnedFd` for relevant types, along with Windows counterparts for handles and sockets. Tracking issue: - <https://github.com/rust-lang/rust/issues/87074> RFC: - <https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md>
2021-08-19Auto merge of #88002 - hermitcore:unbox-mutex, r=dtolnaybors-3/+3
Unbox mutexes, condvars and rwlocks on hermit [RustyHermit](https://github.com/hermitcore/rusty-hermit) provides now movable synchronization primitives and we are able to unbox mutexes and condvars.
2021-08-18Rollup merge of #88012 - sunfishcode:sunfishcode/wasi-raw-fd-c-int, ↵Guillaume Gomez-47/+69
r=alexcrichton Change WASI's `RawFd` from `u32` to `c_int` (`i32`). WASI previously used `u32` as its `RawFd` type, since its "file descriptors" are unsigned table indices, and there's no fundamental reason why WASI can't have more than 2^31 handles. However, this creates myriad little incompability problems with code that also supports Unix platforms, where `RawFd` is `c_int`. While WASI isn't a Unix, it often shares code with Unix, and this difference made such shared code inconvenient. #87329 is the most recent example of such code. So, switch WASI to use `c_int`, which is `i32`. This will mean that code intending to support WASI should ideally avoid assuming that negative file descriptors are invalid, even though POSIX itself says that file descriptors are never negative. This is a breaking change, but `RawFd` is considerd an experimental feature in [the documentation]. [the documentation]: https://doc.rust-lang.org/stable/std/os/wasi/io/type.RawFd.html r? `@alexcrichton`
2021-08-13Change WASI's `RawFd` from `u32` to `c_int` (`i32`).Dan Gohman-47/+69
WASI previously used `u32` as its `RawFd` type, since its "file descriptors" are unsigned table indices, and there's no fundamental reason why WASI can't have more than 2^31 handles. However, this creates myriad little incompability problems with code that also supports Unix platforms, where `RawFd` is `c_int`. While WASI isn't a Unix, it often shares code with Unix, and this difference made such shared code inconvenient. #87329 is the most recent example of such code. So, switch WASI to use `c_int`, which is `i32`. This will mean that code intending to support WASI should ideally avoid assuming that negative file descriptors are invalid, even though POSIX itself says that file descriptors are never negative. This is a breaking change, but `RawFd` is considerd an experimental feature in [the documentation]. [the documentation]: https://doc.rust-lang.org/stable/std/os/wasi/io/type.RawFd.html
2021-08-13Don't put hermit mutexes in a box.Martin Kröning-1/+1
Hermit mutexes are movable.
2021-08-13Don't put hermit condvars in a box.Martin Kröning-1/+1
Hermit condvars are movable.
2021-08-13Don't put hermit rwlocks in a box.Martin Kröning-1/+1
Hermit rwlocks are movable.
2021-08-12Auto merge of #87963 - GuillaumeGomez:rollup-e54sbez, r=GuillaumeGomezbors-5/+24
Rollup of 4 pull requests Successful merges: - #87819 (Use a more accurate span on assoc types WF checks) - #87863 (Fix Windows Command::env("PATH")) - #87885 (Link to edition guide instead of issues for 2021 lints.) - #87941 (Fix/improve rustdoc-js tool) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-08-10STD support for the ESP-IDF frameworkivmarkov-42/+336
2021-08-08Implement modern Windows arg parsingChris Denton-106/+153
As derived from extensive testing of `argv` in a C/C++ application. Co-Authored-By: Jane Lusby <jlusby42@gmail.com>
2021-08-08Update Windows arg parsing testsChris Denton-17/+47
This updates the tests to be consistent with argv in modern C/C++ applications.
2021-08-08Fix Windows Command::env("PATH")Chris Denton-5/+24
2021-08-07Auto merge of #87810 - devnexen:haiku_os_simpl, r=Mark-Simulacrumbors-33/+8
current_exe haiku code path simplification all of these part of libc
2021-08-06current_exe haiku code path simplification all of these part of libcDavid Carlier-33/+8
2021-08-06Rollup merge of #87561 - devnexen:haiku_thread_build_fix, r=yaahcYuki Okushi-2/+9
thread set_name haiku implementation.
2021-08-02os current_exe using same approach as linux to get always the full absolute pathDavid Carlier-13/+17
but in case of failure (e.g. prcfs not mounted) still using getexecname.
2021-08-02Rollup merge of #86509 - CDirkx:os_str, r=m-ou-seYuki Okushi-10/+276
Move `os_str_bytes` to `sys::unix` Followup to #84967, with `OsStrExt` and `OsStringExt` moved out of `sys_common`, there is no reason anymore for `os_str_bytes` to live in `sys_common` and not in sys. This pr moves it to the location `sys::unix::os_str` and reuses the code on other platforms via `#[path]` (as is common in `sys`) instead of importing.
2021-08-02Rollup merge of #86183 - inquisitivecrystal:env-nul, r=m-ou-seYuki Okushi-35/+19
Change environment variable getters to error recoverably This PR changes the standard library environment variable getter functions to error recoverably (i.e. not panic) when given an invalid value. On some platforms, it is invalid for environment variable names to contain `'\0'` or `'='`, or for their values to contain `'\0'`. Currently, the standard library panics when manipulating environment variables with names or values that violate these invariants. However, this behavior doesn't make a lot of sense, at least in the case of getters. If the environment variable is missing, the standard library just returns an error value, rather than panicking. It doesn't make sense to treat the case where the variable is invalid any differently from that. See the [internals thread](https://internals.rust-lang.org/t/why-should-std-var-panic/14847) for discussion. Thus, this PR changes the functions to error recoverably in this case as well. If desired, I could change the functions that manipulate environment variables in other ways as well. I didn't do that here because it wasn't entirely clear what to change them to. Should they error silently or do something else? If someone tells me how to change them, I'm happy to implement the changes. This fixes #86082, an ICE that arises from the current behavior. It also adds a regression test to make sure the ICE does not occur again in the future. `@rustbot` label +T-libs r? `@joshtriplett`
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-14 22:58:17 +0000