Rollup of 6 pull requests #95100
Closed
Rollup of 6 pull requests #95100
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Muhammad Falak R Wani <[email protected]>
This addresses rust-lang#90964 by making the std API consistent about presenting absent stdio handles on Windows as NULL handles. Stdio handles may be absent due to `#![windows_subsystem = "windows"]`, due to the console being detached, or due to a child process having been launched from a parent where stdio handles are absent. Specifically, this fixes the case of child processes of parents with absent stdio, which previously ended up with `stdin().as_raw_handle()` returning `INVALID_HANDLE_VALUE`, which was surprising, and which overlapped with an unrelated valid handle value. With this patch, `stdin().as_raw_handle()` now returns null in these situation, which is consistent with what it does in the parent process. And, document this in the "Windows Portability Considerations" sections of the relevant documentation.
Before calling `CreateProcessW`, stdio handles are passed through `stdio::get_handle`, which already converts NULL to `INVALID_HANDLE_VALUE`, so we don't need extra checks for NULL after that point.
[Benjamin Lamowski: Reworded commit message after split commit.]
[Benjamin Lamowski: Reworded commit message after split commit.]
As a capability-based microkernel OS, L4Re only has incomplete support for POSIX APIs, in particular it does not implement UIDs and GIDs.
L4Re provides limited POSIX support which includes support for standard I/O streams, and a limited implementation of the standard file handling API. However, because as a capability based OS it strives to only make a local view available to each application, there are currently no standardized special files like /dev/null that could serve to sanitize closed standard FDs. For now, skip any attempts to sanitize standard streams until a more complete POSIX runtime is available.
Copy the relevant trait implementations from the Unix default.
The initial stdlib modifications for L4Re just used the linux specifics directly because they were reasonably close to L4Re's behavior. However, this breaks when Linux-specific code relies on code that is only available for the linux target, such as in rust-lang#81825. Put L4Re into its own platform to avoid such breakage in the future. This uses the Linux-specific code as a starting point, which seems to be in line with other OSes with a unix-y interface such as Fuchsia.
Minimally comply with with rust-lang#87329 to avoid breaking tests on L4Re.
This adds a member fn that converts a slice into a CStr; it is intended to be safer than from_ptr (which is unsafe and may read out of bounds), and more useful than from_bytes_with_nul (which requires that the caller already know where the nul byte is). feature gate: cstr_from_bytes_until_nul Also add an error type FromBytesUntilNulError for this fn.
… r=dtolnay Use verbatim paths for `process::Command` if necessary In rust-lang#89174, the standard library started using verbatim paths so longer paths are usable by default. However, `Command` was originally left out because of the way `CreateProcessW` was being called. This was changed as a side effect of rust-lang#87704 so now `Command` paths can be converted to verbatim too (if necessary).
Update stdlib for the l4re target This PR contains the work by `@humenda` and myself to update standard library support for the x86_64-unknown-l4re-uclibc tier 3 target, split out from humenda/rust as requested in rust-lang#85967. The changes have been rebased on current master and updated in follow up commits by myself. The publishing of the changes is authorized and preferred by the original author. To preserve attribution, when standard library changes were introduced as part of other changes to the compiler, I have kept the changes concerning the standard library and altered the commit messages as indicated. Any incompatibilities have been remedied in follow up commits, so that the PR as a whole should result in a clean update of the target.
…lnay Implement `Write for Cursor<[u8; N]>`, plus `A: Allocator` cursor support This implements `Write for Cursor<[u8; N]>`, and also adds support for generic `A: Allocator` in `Box` and `Vec` cursors. This was inspired by a user questioning why they couldn't write a `Cursor<[u8; N]>`: https://users.rust-lang.org/t/why-vec-and-not-u8-makes-cursor-have-write/68210 Related history: - rust-lang#27197 switched `AsRef<[u8]>` for reading and seeking - rust-lang#67415 tried to use `AsMut<[u8]>` for writing, but did not specialize `Vec`.
…onsole-handle, r=dtolnay Consistently present absent stdio handles on Windows as NULL handles. This addresses rust-lang#90964 by making the std API consistent about presenting absent stdio handles on Windows as NULL handles. Stdio handles may be absent due to `#![windows_subsystem = "windows"]`, due to the console being detached, or due to a child process having been launched from a parent where stdio handles are absent. Specifically, this fixes the case of child processes of parents with absent stdio, which previously ended up with `stdin().as_raw_handle()` returning `INVALID_HANDLE_VALUE`, which was surprising, and which overlapped with an unrelated valid handle value. With this patch, `stdin().as_raw_handle()` now returns null in these situation, which is consistent with what it does in the parent process. And, document this in the "Windows Portability Considerations" sections of the relevant documentation.
…olnay keyword_docs: document use of `in` with `pub` keyword Signed-off-by: Muhammad Falak R Wani <[email protected]> Fixes: rust-lang#93609
…k-Simulacrum
add `CStr` method that accepts any slice containing a nul-terminated string
I haven't created an issue (tracking or otherwise) for this yet; apologies if my approach isn't correct. This is my first code contribution.
This change adds a member fn that converts a slice into a `CStr`; it is intended to be safer than `from_ptr` (which is unsafe and may read out of bounds), and more useful than `from_bytes_with_nul` (which requires that the caller already know where the nul byte is).
The reason I find this useful is for situations like this:
```rust
let mut buffer = [0u8; 32];
unsafe {
some_c_function(buffer.as_mut_ptr(), buffer.len());
}
let result = CStr::from_bytes_with_nul(&buffer).unwrap();
```
This code above returns an error with `kind = InteriorNul`, because `from_bytes_with_nul` expects that the caller has passed in a slice with the NUL byte at the end of the slice. But if I just got back a nul-terminated string from some FFI function, I probably don't know where the NUL byte is.
I would wish for a `CStr` constructor with the following properties:
- Accept `&[u8]` as input
- Scan for the first NUL byte and return the `CStr` that spans the correct sub-slice (see [future note below](rust-lang#94984 (comment))).
- Return an error if no NUL byte is found within the input slice
I asked on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/CStr.20from.20.26.5Bu8.5D.20without.20knowing.20the.20NUL.20location.3F) whether this sounded like a good idea, and got a couple of positive-sounding responses from `@joshtriplett` and `@AzureMarker.`
This is my first draft, so feedback is welcome.
A few issues that definitely need feedback:
1. Naming. `@joshtriplett` called this `from_bytes_with_internal_nul` on Zulip, but after staring at all of the available methods, I believe that this function is probably what end users want (rather than the existing fn `from_bytes_with_nul`). Giving it a simpler name (**`from_bytes`**) implies that this should be their first choice.
2. Should I add a similar method on `CString` that accepts `Vec<u8>`? I'd assume the answer is probably yes, but I figured I'd try to get early feedback before making this change bigger.
3. What should the error type look like? I made a unit struct since `CStr::from_bytes` can only fail in one obvious way, but if I need to do this for `CString` as well then that one may want to return `FromVecWithNulError`. And maybe that should dictate the shape of the `CStr` error type also?
Also, cc `@poliorcetics` who wrote rust-lang#73139 containing similar fns.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
process::Commandif necessary #92519 (Use verbatim paths forprocess::Commandif necessary)Write for Cursor<[u8; N]>, plusA: Allocatorcursor support #92663 (ImplementWrite for Cursor<[u8; N]>, plusA: Allocatorcursor support)inwithpubkeyword #93692 (keyword_docs: document use ofinwithpubkeyword)CStrmethod that accepts any slice containing a nul-terminated string #94984 (addCStrmethod that accepts any slice containing a nul-terminated string)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup