-
Notifications
You must be signed in to change notification settings - Fork 238
Rust cleanup #6789
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
base: dev
Are you sure you want to change the base?
Rust cleanup #6789
Conversation
…ersion can be tolerated Still need to go and audit all usage, but realistically the most important places to give the user control are with symbols, where the data can come from non utf8 sources This is still incomplete, I just looked for usage of -> BnString so any other variant was omitted.
@@ -69,11 +69,26 @@ impl BnString { | |||
} | |||
} | |||
|
|||
/// Take an owned core string and convert it to [`String`]. | |||
/// | |||
/// This expects the passed raw string to be owned, as in, freed by us. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably document the behavior when the input contains non-UTF-8 characters.
let bn_settings_file_name = unsafe { BnString::from_raw(settings_file_name_ptr) }; | ||
PathBuf::from(bn_settings_file_name.to_string()) | ||
let settings_file_path_str = unsafe { BnString::into_string(settings_file_name_ptr) }; | ||
PathBuf::from(settings_file_path_str) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
File system paths are not required to be UTF-8 on all platforms. I don't know whether it matters for these sorts of paths, but it could be handled by going from a BnString
to an OsStr
then to a PathBuf
rather than via String
.
We don't need to introduce extra global state when the goal is to not release floating licenses in shutdown.
Threw this on the branch, still need to run more tests, I wouldn't spend time looking at it right now. |
Followup to #5897 This simplifies usage of the trait in user code, should just be able to `to_cstr` to get the cstr repr and then call `as_ptr`. Co-authored-by: Michael Krasnitski <[email protected]>
`cstring.as_ref().as_ptr() as *const c_char` -> `cstring.as_ptr()` `cstring.as_ref().as_ptr() as *mut _` -> `cstring.as_ptr()` `cstring.as_ptr() as *const c_char` -> `cstring.as_ptr()` With a few fixes for cstrings that might be dropped prematurely.
Section names come from the binary itself, we want to preserve the name as is
- Removed `to_string` shortcut from `BnString`. - Misc formatting
CC @mkrasnitski I added you as a co-author to e66b878 seeing as it is effectively a continuation of your PR. Let me know if that is alright, and also if you have any input into this PR. |
Why not just merge #5897? There are no merge conflicts and then you can rebase this PR on top without the string commit. I did a local rebase to test things, and it also let me compare your string commit with mine. They do essentially the same thing except you add a couple lines to the docstring for |
pub unsafe trait BnStrCompatible { | ||
type Result: AsRef<[u8]>; | ||
pub unsafe trait AsCStr { | ||
type Result: Deref<Target = CStr>; | ||
|
||
fn into_bytes_with_nul(self) -> Self::Result; | ||
fn to_cstr(self) -> Self::Result; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having to_cstr
take ownership can lead to some footguns around pointers to temporaries the same way BnStrCompatible
did. In my PR, I have as_cstr
borrow &self
so that writing as_cstr().as_ptr()
inline isn't a problem except if we're dealing with iterators of string-like objects where a local collection of &CStr
needs to be created first, and then another collection of pointers. That also lets me return a concrete Cow<'_, CStr>
given that I have access to the lifetime &self
, instead of requiring an associated type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Cow lifetime does not affect how long the owned memory lives:
bad
is still bad with your PR, it will free the underlying memory even if you tie the lifetime of &self to Cow.
For 1 I think this is pretty easy migration for users, they will just need remove the extra bound, build errors are descriptive enough.
For 2 this just means that users are more responsible for handling invalid UTF-8 which is the correct call in the cases where we cant already just make that assumption, or that a lossy conversion is acceptable.
I need to move on to some other tasks so this PR will likely not grow, I am going to mark this ready for review.
CC: @bdash @rbran
Related: #6784 #6778