Skip to content
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

CStr unchecked constructor can be a const fn #54678

Closed
Tracked by #90343
abonander opened this issue Sep 29, 2018 · 4 comments · Fixed by #54745
Closed
Tracked by #90343

CStr unchecked constructor can be a const fn #54678

abonander opened this issue Sep 29, 2018 · 4 comments · Fixed by #54745
Labels
A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@abonander
Copy link
Contributor

The current implementation of CStr::from_bytes_with_nul_unchecked() is not valid in a const context, but it can easily be tweaked so that it is:

pub const unsafe fn from_bytes_with_nul_unchecked(bytes: &[u8]) -> &Self {
    union BytesToCStr<'a> {
        bytes: &'a [u8],
        cstr: &'a CStr,
    }
    
    BytesToCStr { bytes }.cstr
}
@Havvy Havvy added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Sep 29, 2018
@oli-obk
Copy link
Contributor

oli-obk commented Oct 2, 2018

At this point you can just enable the const_transmute feature gate and use transmute. There's no need for unions anymore

@abonander
Copy link
Contributor Author

@oli-obk I thought transmute was explicitly not going to become const as per the discussion in #49450.

@abonander
Copy link
Contributor Author

Alternatively, why can't we make DST constructors work for simple wrappers like this? Why can't it be, e.g.

&CStr{ bytes: *bytes }

Where it looks kind of like the opposite of a deref coercion, and the compiler just reinterprets the fat pointer? This would eliminate the need for any unsafe besides what's necessary for the API contract.

@oli-obk
Copy link
Contributor

oli-obk commented Oct 2, 2018

Yes I would like such constructors, too. But that needs and RFC and probably has a lot of caveats that we want to think about.

I did not know about that issue. I commented there.

abonander added a commit to abonander/rust that referenced this issue Oct 2, 2018
abonander added a commit to abonander/rust that referenced this issue Oct 2, 2018
pietroalbini added a commit to pietroalbini/rust that referenced this issue Oct 2, 2018
make `CStr::from_bytes_with_nul_unchecked()` a const fn

closes rust-lang#54678
pietroalbini added a commit to pietroalbini/rust that referenced this issue Oct 2, 2018
make `CStr::from_bytes_with_nul_unchecked()` a const fn

closes rust-lang#54678
ischeinkman pushed a commit to ischeinkman/libnx-rs-std that referenced this issue Dec 20, 2018
ischeinkman pushed a commit to ischeinkman/libnx-rs-std that referenced this issue Dec 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-fn Area: const fn foo(..) {..}. Pure functions which can be applied at compile time. C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants