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

Increase MSRV to 1.38 and use ptr.cast::<T>() whenever practical to clarify casts. #425

Merged
merged 3 commits into from
May 26, 2024

Conversation

briansmith
Copy link
Contributor

@briansmith briansmith commented May 20, 2024

Avoid anonymous type casts of the form as *{const,mut} _.

Make it clearer that we're never casting away constness by avoiding as *mut T whenever practical.

@briansmith briansmith force-pushed the b/cast-1 branch 2 times, most recently from 9b31049 to 334178c Compare May 20, 2024 21:19
@briansmith
Copy link
Contributor Author

This change would require bumping the MSRV from 1.36 to 1.38, which I think is worthwhile.

@newpavlov
Copy link
Member

As noted here, we are likely to release v0.3 somewhere in the near future, so I think this change can wait until then.

@briansmith briansmith changed the title Use ptr.cast::<T>() whenever practical to clarify casts. Increase MSRV to 1.38 and use ptr.cast::<T>() whenever practical to clarify casts. May 20, 2024
@@ -14,7 +14,7 @@ extern "C" {
}

pub fn getrandom_inner(dest: &mut [MaybeUninit<u8>]) -> Result<(), Error> {
let ret = unsafe { CCRandomGenerateBytes(dest.as_mut_ptr() as *mut c_void, dest.len()) };
let ret = unsafe { CCRandomGenerateBytes(dest.as_mut_ptr().cast::<c_void>(), dest.len()) };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can rely on type inference and use just .cast().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intentionally avoid using type inference so that we ensure we're casting to the expected type. That is one of the goals of this change.

Copy link
Member

@newpavlov newpavlov May 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it helps in any practical way in this case. In the first place, pointer types do not matter on the ABI level, so we are doing casting to just satisfy conventional signature of external functions. Also, IIRC std also uses a lot of pointer casts which rely on type inference in cases like this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't seem to help in our code because our code does seem to be correct. But this style of explicitly naming the type has helped prevent bugs in practice in other code, and it makes the code easier to audit (from my own experience).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@josephlr WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally like having the type explicit in the cast. It makes it easier for me to understand what's going on. It's not a huge deal, but it is nice to confirm that nothing unexpected is happening with the cast.

src/util_libc.rs Outdated Show resolved Hide resolved
src/util_libc.rs Show resolved Hide resolved
@briansmith briansmith force-pushed the b/cast-1 branch 3 times, most recently from 451083c to b5c89a6 Compare May 21, 2024 03:03
@briansmith briansmith force-pushed the b/cast-1 branch 4 times, most recently from 7094852 to 7617036 Compare May 22, 2024 20:48
@briansmith
Copy link
Contributor Author

I moved the slice aspect to #431.

Copy link
Member

@josephlr josephlr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this!

I'll wait for @newpavlov to approve before merging because this does bump the MSRV, but I think that's fine.

@@ -14,7 +14,7 @@ extern "C" {
}

pub fn getrandom_inner(dest: &mut [MaybeUninit<u8>]) -> Result<(), Error> {
let ret = unsafe { CCRandomGenerateBytes(dest.as_mut_ptr() as *mut c_void, dest.len()) };
let ret = unsafe { CCRandomGenerateBytes(dest.as_mut_ptr().cast::<c_void>(), dest.len()) };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally like having the type explicit in the cast. It makes it easier for me to understand what's going on. It's not a huge deal, but it is nice to confirm that nothing unexpected is happening with the cast.

@newpavlov
Copy link
Member

I am fine with this change, but I think we can wait until v0.3 release, especially considering that it's just a code readability improvement. We also could use the new breaking release to relax our current MSRV policy.

@josephlr josephlr mentioned this pull request May 26, 2024
@josephlr
Copy link
Member

I am fine with this change, but I think we can wait until v0.3 release, especially considering that it's just a code readability improvement. We also could use the new breaking release to relax our current MSRV policy.

I'll merge this then, and I opened #433 to have discussion on if this and similar changes should count as a breaking change or not.

@josephlr josephlr merged commit 1390386 into rust-random:master May 26, 2024
51 checks passed
@briansmith briansmith deleted the b/cast-1 branch May 27, 2024 19:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants