The scope of the unsafe block can be appropriately reduced

[peamaeq]

In this function you use the unsafe keyword for some safe expressions. However, I found that only 6 functions are real unsafe operations (see the list below).

We need to mark unsafe operations more precisely using unsafe keyword. Keeping unsafe blocks small can bring many benefits. For example, when mistakes happen, we can locate any errors related to memory safety within an unsafe block. This is the balance between Safe and Unsafe Rust. The separation is designed to make using Safe Rust as ergonomic as possible, but requires extra effort and care when writing Unsafe Rust. Real unsafe operation list:

1. the win_to_rgba()\offset()\set_len()\GetDIBits()\CreateDIBitmap()\GetDC() function(these are unsafe functions)

Hope this PR can help you. Best regards. References https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

[kjvalencik]

@peamaeq I'll leave it to others who maintain this crate to make the decision; however, in my opinion, it is not always best to scope unsafe as small as possible.

There are two thoughts about the scope of unsafe. The first, is as you described, limiting it to only unsafe calls. However, the other is that it should also include code that enforce invariants that the unsafe call depends on.

For example, in this code the call to GetDIBits relies on result_bytes having not been dropped and no other mutable references to it existing.

[complexspaces]

I agree with K.J here. There are many subtleties with all of the buffer copying in the image handling so I don't think this is ideal.

Additionally, this user is apparently a bot, so I don't think this matters much anyway.