Mark free_str function as unsafe

[kitcatier]

fastrank/src/lib.rs

Lines 77 to 79 in 4d3b57f

	pub extern "C" fn free_str(originally_from_rust: *mut c_void) {
	let _will_drop: CString = unsafe { CString::from_raw(originally_from_rust as *mut c_char) };
	}

Hello, this function needs the unsafe keyword, because when we use the from_raw method, we are converting a raw pointer into a CString object, which is an unsafe operation. It requires us to guarantee that the passed pointer is valid, the pointed-to memory is not freed, and it meets the constraints of the CString type (i.e., null-terminated). Therefore, to avoid potential memory safety issues, we must use the unsafe keyword to mark this operation and explicitly indicate that it is an unsafe operation.
https://doc.rust-lang.org/std/ffi/struct.CString.html#method.from_raw
it is not a good choice to mark the entire function body as unsafe, which will make the caller ignore the safety requirements that the function parameters must guarantee, the developer who calls the free_str function may not notice this safety requirement.
Marking them unsafe also means that callers must make sure they know what they're doing.

[jjfiv]

@kitcatier Thank you for bringing this up; while I agree that these functions should be marked unsafe in a rust library; these are not a rust library, but exposing the rust library to C (so it can be called from python).

In almost any way that matters, the entire module and entire C API is unsafe, like all C APIs. I'm supportive of these changes for the single-line "free" functions, but I like having the absolutely minimal unsafe blocks that are here, because I want the unsafe parts of the FFI bindings to be obvious, and have as much "safe" code as possible in these unsafe blocks.

Perhaps the "this entire module is unsafe" could be documented better.

This module should probably be rewritten to use PyO3, but last I looked there was no e.g., numpy array support in the more stable abi3 in Python, so I've left the "raw FFI" but there may be some better tools for that now.

[jjfiv]

For this function and the following, I was following the philosphy of "the smaller unsafe blocks the better". I don't want to mark the whole functions as unsafe because then more unsafe behavior can be added to the function without the compiler noticing.

[kitcatier]

The philosophy of "the smaller the unsafe block, the better" is very correct

[jjfiv]

#56 introduced to have macros write this unsafe for us.