FFI C code should use uint32_t not size_t for u32 Rust parameters.

[thomcc]

While going over the crates in my onboarding session, I noticed that our FFI layer uses size_t from C and u32 from Rust. One example of several:

https://github.com/ockam-network/ockam/blob/ffadf0633adcae4d0a061fa322fb17dd15afe6e6/implementations/rust/ockam/ockam_ffi/src/vault.rs#L60

https://github.com/ockam-network/ockam/blob/ffadf0633adcae4d0a061fa322fb17dd15afe6e6/implementations/rust/ockam/ockam_ffi/include/vault.h#L72

This is both not guaranteed to work, and can cause major issues in general on 64 bit platforms with ABIs that will pack consecutive integers into the same register when they fit (e.g. x86_64, for example) — we're largely saved by the fact that we don't have any functions that use two consecutive size_t arguments (instead, they're typically surrounded by pointers, which prevents packing the two INTEGER-class parameters into the same register on x86_64, and likely the same on other ABIs).

The right type to use here is usize from the Rust, which should be a simple change.

EDIT: Actually given that in theory there are platforms where this isn't guaranteed to be the case (see rust-lang/rust#88340 and https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/.60usize.60.20vs.20.60size_t.60), I think this should be changed so that C uses uint32_t in the code, rather than adjusting the Rust. Sorry for the confusion.

[Hraesvel]

This seems a simple enough task. I've noticed a few other functions where a length is being passed as a size_t. I assume these should receive the same treatment where size_t is used for u32?

This is also my first contribution should this be a chore(rust) commit?

[mrinalwadhwa]

Hi @Hraesvel thank you for picking this 🙏

should this be a chore(rust) commit

It should be a fix(rust): commit.

I've noticed a few other functions where a length is being passed as a size_t. I assume these should receive the same treatment where size_t is used for u32

Yes.

Looking forward to merging you first contribution 🎉

[mrinalwadhwa]

Also when you send the PR ... could you accept our CLA

Read the CLA at
https://www.ockam.io/learn/how-to-guides/contributing/cla/

To accept the CLA please send a different PR to our contributors repo indicating that you accept the CLA by adding your Git/Github details in a row at the end of the CONTRIBUTORS.csv file:
https://github.com/ockam-network/contributors/blob/master/CONTRIBUTORS.csv

Thank you!!