We shouldn't use the host's uint for target sizes.

[jld]

It's unclear how likely we are to ever deal with ≥4GiB things (or possible things; e.g., if an mmapped region is cast to a huge fixed array type or something like that), let alone when cross-compiling from 32-bit to 64-bit, but this is probably something that should be cleaned up.

For comparison, LLVM seems to mostly use uint64_t for sizes; there are a few unsigneds but I think they may all be for cases like individual machine-level values where the sizes can't overflow.

[graydon]

Can you point out examples where this is happening? Just curious which instances you're referring to.

[jld]

All the ll*size_of* in trans::machine, for one. T_array. There are probably more I'm not thinking of right now.

[pcwalton]

I don't think this is backwards incompatible.

[emberian]

I think this is backwards incompatible. The size of uint changing depending on whether you compiled with a cross compiler or not is weird.

[thestinger]

I don't think it has to do with the size of uint changing but rather the sizes used in the compiler.

[graydon]

just a bug, removing milestone/nomination.

[emberian]

This should be fairly easy to do. Just change uint to u64 as appropriate... in all of the places in trans.

[nathanielherman]

Is this still wanted? I can tackle this if so. I presume we want to make align_of and element_offset stuff in trans::machine also return u64's instead of uint's?

[alexcrichton]

Closed by #11759, thanks @nathanielherman!

[eddyb]

Found more issues:

// middle::trans::common:
pub fn C_int(ccx: &CrateContext, i: int) -> ValueRef {...}
pub fn C_uint(ccx: &CrateContext, i: uint) -> ValueRef {...}

These look like they would truncate values when cross-compiling from a 32-bit architecture to a 64-bit one.

[errordeveloper]

@huonw @eddyb is this still and issue and is anyone going to work on it?

@eddyb looks like the code you referred to is still there...

[frewsxcv]

The code in question that @eddyb mentioned

[nagisa]

The code in question now uses AsU64 and AsI64.

[steveklabnik]

There's been a lot of ongoing work to move away from usize to specific sizes where it makes sense, so I don't think this ticket is particularly useful anymore.