Unsafe functions vs unsafe blocks

[ustulation]

Is there any particular reason why you use unsafe block as opposed to unsafe functions in places like these ?

Wouldn't it be better/accurate to write it as:

#[no_mangle]
pub unsafe extern fn zip_code_database_population_of(ptr: *const ZipCodeDatabase, zip: *const c_char) -> uint32_t {

and remove unsafe blocks inside ?

This is indicating that ptr maybe something non-verifiable - e.g. you can even give something that points to something other than ZipCodeDatabase (completely different object/memory-layout) in which case it is UB and so on and so forth.

I am coding FFI's myself so just wandering if there is any particular reason to choose one over other in this scenario.

[shepmaster]

A good question! My thinking was around the fact that the unsafe blocks provide documentation about what makes them "safe". Your point about passing the wrong type via pointer kind of blows a hole in that (although I don't see any way around it).

Marking the entire function as unsafe is kind of nice from a symmetry point of view - functions imported from C are naturally unsafe. I wonder where we can get some more points of view to help decide...

[scooter-dangle]

I'm for marking the entire function as unsafe. If it's something where the safety relies on user input, then it's unsafe. Not marking it as unsafe feels like false advertising to the developer considering using it. (This is part of why, in recent projects requiring FFI bindings, I write the bindings in the non-Rust language and only support use of the Rust library through those bindings. The 'safe module', in this case, extends across the FFI boundary.)

[shepmaster]

After review, I think that it is more correct to have the function marked as unsafe to indicate to callers that they are responsible for ensuring the safety. There's a proposed RFC 2585 that would make it so that an unsafe fn wouldn't imply an unsafe block, which would make me a lot happier about such a change, however. Right now, the unsafety can be "scoped" to a handful of lines, but when you make the function unsafe, that extra unsafe block will trigger a warning.

We could assume the RFC would be accepted and attempt to code to those standards today by ignoring the warning, but it's a brittle path.