Bring back the ring::c internal C types module.

[briansmith]

No description provided.

[briansmith]

@josephlr @elichai @jonas-schievink PTAL.

A long time ago we had a ring::c module like this and we defined all the C types ourselves. We even had tests to verify that the size and alignment of each type matched between Rust and C. We got rid of all of that because somebody suggested it would be better to just delegate all of this to libc, thinking there's no reason libc wouldn't define these types when it makes sense to do so. Apparently that's wrong. So, this reverts to an internal API that is similar to the old ring::c API, but where the types are still implemented as aliases of libc types. This should reduce the amount of code that would need to be directly impacted by supporting non-libc sources of these types. In particular, this gives us the flexibility to, on a per-target basis, choose to use libc's types, another crate's types, or an internal definitions of the types (like ring originally did).

[josephlr]

This is a good first step. Just a few comment related nits and some issues that should probably be addressed, but can wait for future PRs.

[josephlr]

Add a comment explaining that this is to support cpu::arm::linux_setup() and the cfg should be kept in sync with the one there.

[briansmith]

In general I don't add comments like this because they get out of date. One can use Find Usages or similar in their IDE to see what is using what.

[josephlr]

Add a comment mentioning that this is to support getrandom(2) or merge #83, then this can be removed.

[josephlr]

We could just use usize instead throughout ring as suggested in #837 (comment). Note that many of the places ring uses size_t it should really be using uintptr_t; however, BoringSSL also makes this "mistake" in thinking that sizeof(size_t) == sizeof(void *), so it might just be easier to assume size_t == uintptr_t in which case (as libc::uintptr_t == usize), we can just use usize throughout ring.

This could be addressed now, or in a future PR. We might also want to wait until rust-lang/libc#1400 is resolved.

[briansmith]

Note that many of the places ring uses size_t it should really be using uintptr_t

Could you provide an example?

Rust has made a mistake where it is only well defined on platforms where uintptr_t and size_t and usize are the same type; whenever size_t and uintptr_t are incompatible then Rust can't work given how usize is defined. I'm hoping a future edition of Rust will correct this. This is actually the reason I prefer to keep using size_t everywhere in Rust where size_t is used in the C code.

BoringSSL also makes this "mistake" in thinking that sizeof(size_t) == sizeof(void *)

I think you may be misunderstanding the example you pointed out; the test in that code fragment has to do with whether 64-bit arithmetic is native or not, nothing about pointers. https://boringssl.googlesource.com/boringssl/+/8f574c37dae935a29bff56e750101e5b354503de/crypto/fipsmodule/bn/exponentiation.c#895 would be an example where size_t is used instead of uintptr_t in BoringSSL. I believe we've eliminated all such confusion in ring already; see #68, #151, and in particular #101.

[josephlr]

Rust has a target-c-int-width attribute that we could use to define c::int instead of relying on libc. However, this is best addressed in a future PR.

[briansmith]

Rust has a target-c-int-width attribute that we could use to define c::int instead of relying on libc. However, this is best addressed in a future PR.

That would be awesome to use if it works! Can you give an example? I tried #[cfg(target_c_int_width = "32")] type int = i32; but target_c_int_width doesn't seem to be exposed for #[cfg(...)] to use.