The scope of the unsafe block can be appropriately reduced

[peamaeq]

Can shrink unsafe blocks

[weiznich]

Thanks for opening this PR.

Can you please provide some reasoning why this is a better way to handle these unsafe code block? This does not really reduce the scope of anything, it just introduces more blocks with basically the same scope. At least in my opinion thats not a meaningful change.

[weiznich]

This is one of the relevant change in this PR.

[mohe2015]

I'm really no expert with unsafe but my understanding is that you should choose the scopes as small as possible and such that any code outside of the unsafe block can't use it's results to cause havoc. Then people only have to look at these small unsafe blocks and as long as they consider them "safe" the whole code should be safe.

[weiznich]

I'm really no expert with unsafe but my understanding is that you should choose the scopes as small as possible and such that any code outside of the unsafe block can't use it's results to cause havoc. Then people only have to look at these small unsafe blocks and as long as they consider them "safe" the whole code should be safe.

This is generally true. The problem with this PR is that it introduces largely changes like the following:

unsafe {
    let error_ptr = PQerrorMessage(conn);
    let bytes = CStr::from_ptr(error_ptr).to_bytes();
    String::from_utf8_lossy(bytes).to_string()
}

is replaced by something like

    let error_ptr = unsafe { PQerrorMessage(conn) };      
    let bytes = unsafe { CStr::from_ptr(error_ptr).to_bytes() };      
    String::from_utf8_lossy(bytes).to_string()   

My main problem with such a change is that is splits up the unsafe block that groups together the ffi call + the type conversion. Both are unsafe and both belong as unit together. In my opinion it's not meaningful to remove the grouping there and to introduce artificial smaller unsafe blocks there. This makes it harder to read + any person trying to review these blocks will need to understand them both at once as they are only meaningful together. So there is just no benefit of having them split up from my point of view.

(Splitting out the String::from_utf8_lossy call would be fine, if that's the only thing this change would do.)