Rust-bindgen: size_t vs usize

[elichai]

Input C/C++ Header

#include <stddef.h>
static size_t A = 5;

bindgen converts size_t to `usize. but I'm not sure that's correct. the unsafe guidelines(https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html) say that usize==uintptr_t. but the C standard doesn't define that uintptr_t==size_t therefore usize != size_t.

Am I missing something?

[highfive]

Hi! If you have any questions regarding this issue, feel free to make a comment here, or ask it in the #servo channel in IRC.

If you intend to work on this issue, then add @highfive: assign me to your comment, and I'll assign this to you. :smile:

[emilio]

You're _technically_ correct, I think (which is the best kind of correct ;)).

In practice, in all platforms that I know of sizeof(size_t) == sizeof(uintptr_t). See https://stackoverflow.com/questions/1464174/size-t-vs-uintptr-t.

But we should probably avoid doing this transformation, should be straight-forward.

[cmcavity]

Hi I'd like to work on this. Should the ssize_t to isize transformation be removed as well?
@highfive: assign me

[highfive]

Hey @cmcavity! Thanks for your interest in working on this issue. It's now assigned to you!

[cmcavity]

@emilio This issue should be closed after pull request #1688.

[emilio]

Fixed by the above PR.

[quidity]

For posterity, a flag was added to revert to previous behavior: --size_t-is-usize

https://github.com/rust-lang/rust-bindgen/commit/f96dcf97f09182093bc7b82cd5f9b388e89afc44

[vext01]

Hi folks,

I have a scenario where bindgen has generated a u64 for a size_t. I think that's wrong. E.g. on i386 a size_t will be 4-bytes, but a u64 is always 8.

Here @emilio suggested I should try --size_t-is-usize, but I'm confused.

It's not clear to me if this is the same issue, as here you are talking about size_t and usize (not size_t and u64)...

The issue starts with version 0.53 of bindgen.

Can anyone shed some light?

[emilio]

Bindgen by default will peek the right size depending on the target architecture. So if you run bindgen with a 64-bit target it'll use u64, with a 32-bit target it'll use u32. If you enable size_t-is-usize then it'll assume that size_t is always usize, and generate usize instead of u32 / u64.

[vext01]

Ah, I see.

I wonder why size_t-is-usize isn't default. It seems to me that this is what most people would want/expect.

(Sorry for all the questions)

[geofft]

Is bindgen able to assert that size_t and uintptr_t are the same on my platform, such that it can tell me that --size_t-is-usize is safe?

I was thinking of writing something to test this, but it seems like bindgen probably has enough access to the C compiler to make that check doable?

[emilio]

@geofft potentially, but other than asserting and aborting if we detect it's not safe we couldn't do much else. We have target_pointer_size. When generating size_t we also have the size of that type, so we could assert there and abort, or add a #[test] fn or something.

[geofft]

Yeah, asserting and aborting is the behavior I want - the platforms where this is not true are niche and I'd have to change many other parts of my bindings to safely handle them, I think.

This might be asking too much, but, one approach might be to revert the default back to treating size_t as usize, but with such an assertion added (i.e., it fails to compile on platforms where they're incompatible), and if you specifically want to support these other platforms, allow passing an option to say that size_t _isn't_ usize.

[dkg]

fwiw, i agree with @geofft that bindgen's defaults for size_t_is_usize should be true, and a warning should be issued on any platform where size_t isn't usize.

[dkg]

I've opened #1901 to encourage bindgen to change the default back to true, and to abort when building on a platform where usize and size_t are not congruent unless it is deliberately reset to false.