Skip to content

Tracking Issue for CStr::from_bytes_until_nul #95027

Closed

Description

@ericseppanen

Feature gate: #![feature(cstr_from_bytes_until_nul)]

This is a tracking issue for adding member fn to CStr that convert from a byte slice, without the caller needing to know where the nul byte is located within the slice.

This is intended for use in FFI calls, where a foreign function wrote a string into a Rust-allocated buffer. The existing member fns fall short in this case:

  • CStr::from_ptr is unsafe and may read past the end of the buffer if no nul byte is found.
  • CStr::from_bytes_with_nul only works if there is exactly one nul byte at the end of the slice.

The proposed new member fn (tentatively named from_bytes_until_nul) is easier and can be used safely on any byte slice.

Public API

// std::ffi:

pub struct FromBytesUntilNulError(...);

impl CStr {
    pub fn from_bytes_until_nul(bytes: &[u8]) -> Result<&CStr, FromBytesUntilNulError>;
}

Steps / History

Unresolved Questions

Activity

  1. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    T-libs-api[DEPRECATED; DO NOT USE]
    on Mar 16, 2022
  2. Stargateur commented on Aug 1, 2022

    @Stargateur
    Contributor

    CStr::from_bytes_with_nul only works if there is exactly one nul byte at the end of the slice.

    That a better doc that real doc

    ensuring that the byte slice is nul-terminated and does not contain any interior nul bytes.

    for exemple, [97, 98, 99, 100, 0, 0, 0, 0] could be interpreted as no interior nul bytes unlike the example b"he\0llo\0".

  3. jimblandy commented on Oct 6, 2022

    @jimblandy
    Contributor

    We could have avoided the unsafe block that led to gfx-rs/wgpu#3076 by using this function. I hope it gets stabilized.

  4. tgross35 commented on Jan 18, 2023

    @tgross35
    Member

    Would it be possible to separately feature gate cstring_from_bytes_until_nul, instead of both CStr and CString being under cstr_from_bytes_until_nul? I ask because this CStr version is straightforward, has been around for almost a year, is very useful for FFI, and is already mentioned in the forums quite often - imho, probably ready for FCP.

    However, the CString version hasn't even merged yet. I just don't think it's worth delaying the CStr stabilization for another year or so while waiting on CString::from_vec_until_nul to get merged & mature a while.

  5. tgross35 commented on Jan 28, 2023

    @tgross35
    Member

    Hey @ericseppanen I hope you don't mind, but I've opened stabilization PR #107429 without any CString implementation. If you have any concerns just let me know and I can close / adjust it as needed

  6. ericseppanen commented on Jan 29, 2023

    @ericseppanen
    ContributorAuthor

    I'm not sure which issue to comment on, but I'm happy with whatever others want to do. I was never sure why the CString bit (#96186) stalled, but it's at least partially my own fault as I was too shy to beg for more reviews.

    I'll try to find time to rebase that commit and poke the reviewers again.

  7. tgross35 commented on Jan 29, 2023

    @tgross35
    Member

    Okiedoke, as long as you don't have any qualms about the cstr part going stable. Sorry to leapfrog you and start the stabilization, but I wasn't sure if you were still active on github.

    Yeah, things have a tendency to stall a bit when they're close to the merge phase and there isn't really any open debate or strong need to drive discussion. Not your fault!

  8. changed the title [-]Tracking Issue for `CString`/`CStr::from_bytes_until_nul`[/-] [+]Tracking Issue for `CStr::from_bytes_until_nul`[/+] on Jan 30, 2023
  9. m-ou-se commented on Jan 30, 2023

    @m-ou-se
    Member

    Would it be possible to separately feature gate cstring_from_bytes_until_nul, instead of both CStr and CString being under cstr_from_bytes_until_nul?

    Good idea. I've edited this tracking issue so it only covers CStr::from_bytes_until_nul.

  10. added 3 commits that reference this issue on Feb 9, 2023
  11. tgross35 commented on Jul 1, 2023

    @tgross35
    Member

    Since cstr_from_bytes_until_nul has been stabilized (#107429 1.69), I think this issue could be closed. @ericseppanen do you perhaps want to start a new tracking issue for cstring_from_bytes_until_nul?

  12. ericseppanen commented on Jul 1, 2023

    @ericseppanen
    ContributorAuthor

    Sure, we can close this. I'm not sure if a new tracking issue is needed, since the CString::from_vec_until_nul PR (#96186) is not making progress. If someone wants to bring it back to life, feel free to persuade the reviewers.

  13. tgross35 commented on Jul 1, 2023

    @tgross35
    Member

    Fwiw that PR is labeled waiting on author, you can comment @rustbot ready to change it to waiting on review

  14. aswild commented on Jul 13, 2023

    @aswild
    Contributor

    Hi @ericseppanen,
    Was it intentional to add FromBytesUntilNulError only in core::ffi and not re-export it in std::ffi?

    I'm used to everything from core (and alloc) to be re-exported under the same name in std, so it was a bit of a surprise to see an error message when trying to use std::ffi::{CStr, FromBytesUntilNulError}.

  15. tgross35 commented on Jul 13, 2023

    @tgross35
    Member

    @aswild I don't think anybody would object to a reexport - are you interested in making a PR for that change?

    It would need to go through FCP (as it changes public API) but I think it's small enough that that could happen on the PR.

  16. ericseppanen commented on Jul 13, 2023

    @ericseppanen
    ContributorAuthor

    Hi @ericseppanen, Was it intentional to add FromBytesUntilNulError only in core::ffi and not re-export it in std::ffi?

    Not intentional; probably just me not knowing I was supposed to do it.

  17. aswild commented on Jul 14, 2023

    @aswild
    Contributor

    Sure, I can give making a PR a try! I haven't contributed to the standard library before so I apologize in advance if I get the #[stable] attribute wrong at first.

  18. added a commit that references this issue on Jul 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-api[DEPRECATED; DO NOT USE]

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions