incorrect use of unsafe about crc32c HOT 4 CLOSED

Thanks for the feedback.

The entire point of the crate is to make the determination of software vs. hardware and abstract that via the top-level func. I'll admit there is some internal mess around unsafe, which I'll address.

I'm not sure I follow why a top-level type is necessary in this case. Could you elaborate as to why your proposed SSE42 type is necessary?

from crc32c.

My suggestion is one possible solution. What's necessary is to ensure that you do not define a safe function that can be called that doesn't satisfy the assumptions that its use of unsafe requires.

from crc32c.

Another possible solution is to make every function that transitively uses intrinsics in std::arch unsafe, with the exception of your public functions, which are themselves responsible for satisfying the assumptions that std::arch requires.

from crc32c.

Gotcha. That was my initial thought on fixing the unsafe behavior.

from crc32c.