-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilize feature cstr_from_bytes_until_nul
#107429
Stabilize feature cstr_from_bytes_until_nul
#107429
Conversation
r? @cuviper (rustbot has picked a reviewer for you, use r? to override) |
The Miri subtree was changed cc @rust-lang/miri Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
r? libs-api |
36956fc
to
c223206
Compare
@rfcbot merge |
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
@joshtriplett I just replied to that comment, but I wasn’t able to do so because memchr isn’t const stable. Is there a way around that since it’s an internal call? |
It is const. See |
Hm, you're right. But marking it const stable gets this failure https://github.com/rust-lang/rust/actions/runs/4049015645/jobs/6964924272#step:26:777 any clue why? The slice index is also an issue but I think that could be worked around with |
This comment has been minimized.
This comment has been minimized.
Halfway there; |
Ah this is an oddity of our const stability checks. You need to add a |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
@bors r+ |
…bilization, r=dtolnay Stabilize feature `cstr_from_bytes_until_nul` This PR seeks to stabilize `cstr_from_bytes_until_nul`. Partially addresses rust-lang#95027 This function has only been on nightly for about 10 months, but I think it is simple enough that there isn't harm discussing stabilization. It has also had at least a handful of mentions on both the user forum and the discord, so it seems like it's already in use or at least known. This needs FCP still. Comment on potential discussion points: - eventual conversion of `CStr` to be a single thin pointer: this function will still be useful to provide a safe way to create a `CStr` after this change. - should this return a length too, to address concerns about the `CStr` change? I don't see it as being particularly useful, and it seems less ergonomic (i.e. returning `Result<(&CStr, usize), FromBytesUntilNulError>`). I think users that also need this length without the additional `strlen` call are likely better off using a combination of other methods, but this is up for discussion - `CString::from_vec_until_nul`: this is also useful, but it doesn't even have a nightly implementation merged yet. I propose feature gating that separately, as opposed to blocking this `CStr` implementation on that Possible alternatives: A user can use `from_bytes_with_nul` on a slice up to `my_slice[..my_slice.iter().find(|c| c == 0).unwrap()]`. However; that is significantly less ergonomic, and is a bit more work for the compiler to optimize compared the direct `memchr` call that this wraps. ## New stable API ```rs // both in core::ffi pub struct FromBytesUntilNulError(()); impl CStr { pub const fn from_bytes_until_nul( bytes: &[u8] ) -> Result<&CStr, FromBytesUntilNulError> } ``` cc `@ericseppanen` original author, `@Mark-Simulacrum` original reviewer, `@m-ou-se` brought up some issues on the thin pointer CStr `@rustbot` modify labels: +T-libs-api +needs-fcp
…bilization, r=dtolnay Stabilize feature `cstr_from_bytes_until_nul` This PR seeks to stabilize `cstr_from_bytes_until_nul`. Partially addresses rust-lang#95027 This function has only been on nightly for about 10 months, but I think it is simple enough that there isn't harm discussing stabilization. It has also had at least a handful of mentions on both the user forum and the discord, so it seems like it's already in use or at least known. This needs FCP still. Comment on potential discussion points: - eventual conversion of `CStr` to be a single thin pointer: this function will still be useful to provide a safe way to create a `CStr` after this change. - should this return a length too, to address concerns about the `CStr` change? I don't see it as being particularly useful, and it seems less ergonomic (i.e. returning `Result<(&CStr, usize), FromBytesUntilNulError>`). I think users that also need this length without the additional `strlen` call are likely better off using a combination of other methods, but this is up for discussion - `CString::from_vec_until_nul`: this is also useful, but it doesn't even have a nightly implementation merged yet. I propose feature gating that separately, as opposed to blocking this `CStr` implementation on that Possible alternatives: A user can use `from_bytes_with_nul` on a slice up to `my_slice[..my_slice.iter().find(|c| c == 0).unwrap()]`. However; that is significantly less ergonomic, and is a bit more work for the compiler to optimize compared the direct `memchr` call that this wraps. ## New stable API ```rs // both in core::ffi pub struct FromBytesUntilNulError(()); impl CStr { pub const fn from_bytes_until_nul( bytes: &[u8] ) -> Result<&CStr, FromBytesUntilNulError> } ``` cc ``@ericseppanen`` original author, ``@Mark-Simulacrum`` original reviewer, ``@m-ou-se`` brought up some issues on the thin pointer CStr ``@rustbot`` modify labels: +T-libs-api +needs-fcp
…mpiler-errors Rollup of 9 pull requests Successful merges: - rust-lang#107317 (Implement `AsFd` and `AsRawFd` for `Rc`) - rust-lang#107429 (Stabilize feature `cstr_from_bytes_until_nul`) - rust-lang#107713 (Extend `BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE`.) - rust-lang#107761 (Replace a command line flag with an env var to allow tools to initialize the tracing loggers at their own discretion) - rust-lang#107790 ( x.py fails all downloads that use a tempdir with snap curl rust-lang#107722) - rust-lang#107799 (correctly update goals in the cache) - rust-lang#107813 (Do not eagerly recover for bad `impl Trait` types in macros) - rust-lang#107817 (rustdoc: use svgo to shrink `wheel.svg`) - rust-lang#107819 (Set `rust-analyzer.check.invocationLocation` to `root`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Is there any reason for misspelling |
For consistency with the other already stabilized methods. |
It's somewhat common to use "nul" for chars and "null" for pointers. |
the ascii table has always noted the |
This PR seeks to stabilize
cstr_from_bytes_until_nul
.Partially addresses #95027
This function has only been on nightly for about 10 months, but I think it is simple enough that there isn't harm discussing stabilization. It has also had at least a handful of mentions on both the user forum and the discord, so it seems like it's already in use or at least known.
This needs FCP still.
Comment on potential discussion points:
CStr
to be a single thin pointer: this function will still be useful to provide a safe way to create aCStr
after this change.CStr
change? I don't see it as being particularly useful, and it seems less ergonomic (i.e. returningResult<(&CStr, usize), FromBytesUntilNulError>
). I think users that also need this length without the additionalstrlen
call are likely better off using a combination of other methods, but this is up for discussionCString::from_vec_until_nul
: this is also useful, but it doesn't even have a nightly implementation merged yet. I propose feature gating that separately, as opposed to blocking thisCStr
implementation on thatPossible alternatives:
A user can use
from_bytes_with_nul
on a slice up tomy_slice[..my_slice.iter().find(|c| c == 0).unwrap()]
. However; that is significantly less ergonomic, and is a bit more work for the compiler to optimize compared the directmemchr
call that this wraps.New stable API
cc @ericseppanen original author, @Mark-Simulacrum original reviewer, @m-ou-se brought up some issues on the thin pointer CStr
@rustbot modify labels: +T-libs-api +needs-fcp