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.

[pnkfelix]

@thestinger it is not clear to me why the definition of the size_t type should have bearing on the type used to index into Rust vectors.

[thestinger]

size_t exists because there's a distinction between the size of objects (and indexing into them) and pointers. If Rust isn't going to support a distinction between those, it can't support an environment where uintptr_t and size_t are different types. Every API defined with size_t or uintptr_t just gets wrapped by Rust to use uint, so there's no more or less support for it being different based on the type alias alone.

C also doesn't define floating point as having a radix of 2 or even that float and double are 32-bit and 64-bit, so there's not much we're left with if we have to support an underlying C library according to the standard's guarantees alone.

[pnkfelix]

@thestinger okay, reading over your earlier comments I realized that I was misinterpreting your overall message.

[pnkfelix]

team decided to let size_t remain faithful to the definition provided by each host's header files. (This is despite our agreement with @thestinger that to actually support that distinction meaningfully throughout Rust would require serious revamping of the standard library.)

[thestinger]

I agree with leaving it that way FWIW, because I want us to be auto-generating these definitions. :)

I just don't want Rust to try supporting a different sized size_t.