Rust: remove direct dependency on the libc
crate
#5654
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Almost all uses of the
libc
crate were to import types that the standard library already provides, e.g.c_void
,c_char
, etc. We can import those fromstd::ffi
. In some places they were being imported fromstd::os::raw
, so I changed those imports as well, as they are just type aliases for the definitions instd::ffi
anyways.One nontrivial case where
libc
was being used was insidecb_{free_}flag_conditions_for_semantic_flag_group
, which usedlibc::{malloc, free}
. This was changed to usestd::alloc::{alloc, dealloc}
and required some hacky layout calculations in order to smuggle the length of the allocated array across the FFI boundary.Getting rid of this hack would require for the Core API to change such that a
count: usize
parameter is passed tocb_free_flag_conditions_for_semantic_flag_group
(and ideally also tocb_free_register_list
) so that no smuggling would be required and we could just callBox::from_raw(ptr::slice_from_raw_parts_mut(conds, count))
and be done. I'll open a separate issue for that.