Improve FFI safety w.r.t. alignment and sizing

[briansmith]

See the checked_struct branch, particularly, cd53d14.

That is incomplete in that it doesn't address alignment from the Rust side. In particular, we assume that the alignment of u64 is 8 bytes, but we don't assert that.

It is also incomplete because it doesn't do the FFI checking for ring::digest.

[briansmith]

Partially fixed with 377f611. The work mentioned above still needs to be done. More work on checking alignment and size of other primitive types, like pointer types, is also needed.

[briansmith]

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271. On ARM we may need to align to 16 or even 32 bytes for any function that might use NEON instructions that access memory.

[briansmith]

See also http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html

[briansmith]

See also rust-lang/rfcs#325 and rust-lang/rust#26403. Without a fix for that issue, we probably have to work around the problem by padding all our FFI context buffers with 16 or 32 extra bytes, and calculate the aligned addresses ourselves.

[briansmith]

C99 section 7.20.3: "The order and contiguity of storage allocated by successive calls to the calloc, malloc, and realloc functions is unspecified. The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated"

[briansmith]

The situation for ring::digest was mostly fixed in 8cb362f.