size_t should be defined as uint

[nmsmith]

The C-standard definition of size_t states that it must be able to represent the size of any object in bytes. It therefore makes sense for size_t to be defined as uint, to make it equal to the pointer size. Currently (as an example) it's defined as u32 on x86 and u64 on x86-64, but this poses problems with the malloc family of functions in std::libc::funcs::c95::stdlib that accept a size_t, since it is currently invalid to pass them a uint without casting. It makes the most sense to specify the size of a memory allocation with a type of size equal to that of a pointer, so you shouldn't need to do a cast to pass these functions values.

[huonw]

You can work around this by casting a uint to a size_t explicitly:

use std::libc::{malloc, size_t};

unsafe fn foo() { malloc(10u as size_t); }

[nmsmith]

Absolutely, but the ideal solution is to not require any casts.

[brson]

Agree it should be uint.

[brson]

And likewise ssize_t int.

[brson]

Nominating.

[brson]

We should check the spec to make sure size_t and uintptr_t are always the same.

[pnkfelix]

Accepting for P-backcompat-libs

[thestinger]

@brson: They're not necessarily always the same. Although, I think in practice every architecture Rust will target uses the same types for these. Rust assumes they are the same throughout the implementation.

[brson]

I no longer think it should be uint since the C spec doesn't define size_t as being pointer sized.

[nmsmith]

@brson It also doesn't say it shouldn't be pointer-sized (afaik). It doesn't make much sense for malloc to take a size_t if a size_t isn't pointer-sized. That's the main gripe I've had with its current definition so far.

[thestinger]

@ecl3ctic: Some architectures had segmented memory models, and using different sizes for size_t, ptrdiff_t and uintptr_t may have made sense. It's true that Rust is very unlikely to ever target an architecture like that with the standard library. It would require a drastic overhaul.

[brson]

Nominating for closing, per previous discussion: size_t and uint are not specced to be the same in C. The current definition of size_t works though with unfortunate casts in places, but the impact is minor.

[thestinger]

We do assume these are the same throughout the API design of the standard library and the language itself. We would need to change indexing to use size_t if we wanted to support it being different.

[brson]

@thestinger can you expand on that? I do not understand how the definition of size_t impacts anything in Rust.