'int' is enough for 'length' to migrate code from x86 to x64

[ketmar via Digitalmars-d]

On Wed, 19 Nov 2014 13:33:21 +0000
Don via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> No. Signed types do not *wrap*. They *overflow* if their range is 
> exceeded.
same for unsigned ints.

> This is not the same thing. Overflow is always an error.
> And the compiler could insert checks to detect this.
and for unsigned ints. i want compilers to has special code for this.
something like `checkedInt(...)`. and this must be built-in, 'cause
checking carry flag is cheap, but can be done only on "machine" level.

> That's not possible for unsigned types. With an unsigned type, 
> wrapping is part of the semantics.
see above.

> Moreover, hitting an overflow with a signed type is an 
> exceptional situation. Wrapping with an unsigned type is entirely 
> normal, and happens with things like 2u - 1u.
having results of unsigned int wrapping defined doesn't mean that it's
"normal". it's just *defined*, so you can check for it without
triggering UB.

> IMHO the correct solution is to say that the length of a slice 
> cannot exceed half of the memory space, otherwise a runtime error 
> will occur. And then make size_t a positive integer.
but why? maybe 1/3 of address space fits better? or 256 bytes, to
really avoid "overflows" and "wrapping"?

> Then let typeof(size_t - size_t) == int, instead of uint. All 
> other operations stay as size_t.
check and cast. you can check length and then safely cast it to int, no
probs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141119/46d967f1/attachment.sig>