Clarify non-nullable pointer optimization in repr(C) section

[ramosbugs]

Resolves #59

[Gankra]

Looks good, just need to double-check that Box is Actually FFI-Safe, as this is quite surprising to hear

[ramosbugs]

Thanks for the review!

The Nullable Pointer Optimization subsection under FFI calls out boxes since they can't hold null pointers. This makes it seem like they should be FFI-safe since the representation in memory would be the same as for a raw pointer (iiuc). I'm far from an authority on this, so please correct me if I'm wrong!

One potential distinction I see between Box<T> and the other listed types is that since a Box holds Rust-owned data (which is freed using Rust's allocator), it's not suitable to receive pointers from non-Rust code. However, it should be able to provide pointers from Rust to non-Rust code, right?

[Gankra]

There are subtle annoying details about ABI here. Specifically, pointers are a specific kind of thing in ABIs, and a struct containing a pointer does not have the same one. This affects how it would be passed in a function call. I expect we currently do match the ABI, but I'm uncertain that we guarantee it. (why would we?)

[Gankra]

Discussing with @eddyb, we agree we could guarantee the ABI of Box but don't have a strong motivation to do so. All we guarantee about Box is that Option<Box> has the same layout as Box.

[ramosbugs]

Makes sense. I can't see any motivation for guaranteeing that ABI either. Updated the PR.

[Gankra]

Thanks!