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

Use cast instead of transmute #47

Merged
merged 1 commit into from
Oct 30, 2023
Merged

Conversation

kornelski
Copy link
Contributor

NonNull supports cast(), so there's no need for transmute.

@Voultapher
Copy link
Owner

Thanks for the PR. I'm fine with the change, that said I'd like to understand the motivation for the change a bit better. For example one thing I like about transmute is you immediately see and enforce the type you cast from and to, and if you change something you have to go through each relevant transmute and update them, re-evaluating if they are still valid. With cast that would not be a compile time error right?

ptr: unsafe {
transmute::<*mut JoinedCell<Owner, Dependent>, *mut u8>(self.joined_ptr.as_ptr())
},
ptr: self.joined_ptr.as_ptr().cast(),
Copy link
Owner

@Voultapher Voultapher Oct 27, 2023

Choose a reason for hiding this comment

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

Please specify the cast result type here.

@Voultapher
Copy link
Owner

Completely unrelated, I just realized you are the creator of gifski a project I've used quite a bit, thank you for the great project <3

@kornelski
Copy link
Contributor Author

The idea behind this is that transmute is a more powerful, more general-purpose function, and it has power of transmuting types that aren't compatible.

cast() is more specific and directly expresses what is happening, and is implemented only on pointer types.

In your case I think all transmutes are correct. However in general there are cases where transmute of exotically sized pointers is not well-defined (they don't have guaranteed layouts), but cast (which can change pointer layout) is allowed.

@Voultapher
Copy link
Owner

Sounds good. I'm looking into the miri failure that seems unrelated to this change. Please update the PR to be compatible with rustc 1.36 as tested by old_rust_rustc_1_36.

@Voultapher
Copy link
Owner

You should be able to rebase on main now and the miri test should run as expected.

@Voultapher
Copy link
Owner

The CI for this project is a bit dated, and the triggers were wonky. I took the liberty of fixing it on main and rebasing your branch. Change looks good otherwise.

@Voultapher
Copy link
Owner

ptr: self.joined_ptr.as_ptr().cast::<u8>() requires ptr_cast feature which is not available for rustc 1.36. The machinery for polyfilling it only for old rustc versions and if the users opt into the old_rustc feature is there, but I wonder if it is overkill. Thoughts?

@kornelski
Copy link
Contributor Author

Sure, I've replaced that with a regular pointer cast.

BTW, I expect 1.36, and all rust versions below 1.56, to be completely dead and unusable: https://lib.rs/stats#rustc

@Voultapher
Copy link
Owner

I'd be careful about such assumptions, also I have an upstream dependency that specifically asked for this feature #30. As long as it seems reasonably possible to keep the minimum required rustc version the same, I plan on doing so.

@Voultapher Voultapher merged commit 98bdf38 into Voultapher:main Oct 30, 2023
5 checks passed
@Voultapher
Copy link
Owner

I've merged the change, thanks for the PR. I'm not sure if this change has any immediate impact on users, do you think a new release is required?

@kornelski
Copy link
Contributor Author

Thanks. No need to rush with a release.

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.

2 participants