macos: Cleanup SecRandom type

[josephlr]

Right now SecRandom is an uninhabited type. However, opaque pointers
are not supposed to be pointers to uninhabited types or ZSTs. This
issue was solved in core by introducing core::ffi:c_void that just
does all the right things.

This PR:

• Changes SecRandom to be a transparent wrapper around c_void.
• Links kSecRandomDefault instead of defining it ourself.
• Should not change any behavior on macos.

[dhardy]

I wasn't aware of this. I found the section on Handling Zero-Sized Types in the nomicon, but it only talks about issues with allocation and iterators — we don't appear to do either here.

What our version of OpaquePointer is missing is alignment info, though given that we only ever construct the address 0 it shouldn't matter.

Also, I guess usize is always the same as libc::size_t but can we actually rely on that?

[newpavlov]

IIUC this is one of the use-cases for extern types (currently unstable) and uninhabited types is a common workaround, which I've seen in several places. I am not sure if this PR is correct, citing the c_void docs:

To model pointers to opaque types in FFI, until extern type is stabilized, it is recommended to use a newtype wrapper around an empty byte array.

[newpavlov]

You don't need this import anymore.

[josephlr]

Fixed

[josephlr]

I wasn't aware of this. I found the section on Handling Zero-Sized Types in the nomicon, but it only talks about issues with allocation and iterators — we don't appear to do either here.

What our version of OpaquePointer is missing is alignment info, though given that we only ever construct the address 0 it shouldn't matter.

IIUC this is one of the use-cases for extern types (currently unstable) and uninhabited types is a common workaround, which I've seen in several places. I am not sure if this PR is correct, citing the c_void docs:

Whoops, missed that. Fixed to do what the nomicon says (use a private ZST field) and link to the Github issue on extern_type.

Also, I guess usize is always the same as libc::size_t but can we actually rely on that?

So this assumption is built deep into how Rust interfaces with C libraries. If a platform is supportted by libc, size_t is a typedef for usize. This is assumption is also built into things like memcpy. So I'd say it is about as safe a relying on u8, u16, u32, u64 being the same as libc::{uint8_t, uint16_t, uint32_t, uint64_t}