Skip to content

CStr unchecked constructor can be a const fn #54678

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) 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 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
@RalfJung RalfJung added the A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) label Dec 1, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) 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.

4 participants