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

[Don via Digitalmars-d]

On Friday, 21 November 2014 at 08:46:20 UTC, Walter Bright wrote:
> On 11/21/2014 12:10 AM, bearophile wrote:
>> Walter Bright:
>>
>>> All you're doing is trading 0 crossing for 0x7FFFFFFF 
>>> crossing issues, and
>>> pretending the problems have gone away.
>>
>> I'm not pretending anything. I am asking in practical 
>> programming what of the
>> two solutions leads to leas problems/bugs. So far I've seen 
>> the unsigned
>> solution and I've seen it's highly bug-prone.
>
> I'm suggesting that having a bug and detecting the bug are two 
> different things. The 0-crossing bug is easier to detect, but 
> that doesn't mean that shifting the problem to 0x7FFFFFFF 
> crossing bugs is making the bug count less.
>
>
>>> BTW, granted the 0x7FFFFFFF problems exhibit the bugs less 
>>> often, but
>>> paradoxically this can make the bug worse, because then it 
>>> only gets found
>>> much, much later in supposedly tested & robust code.
>>
>> Is this true? Do you have some examples of buggy code?
>
> http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Changing signed to unsigned in that example does NOT fix the bug.
It just means it fails with length = 2^^31 instead of length = 
2^^30.

uint a = 0x8000_0000u;
uint b = 0x8000_0002u;
assert( (a + b) /2 == 0);

But actually I don't understand that article.
The arrays are int, not char. Since length fits into 32 bits, the 
largest possible value is 2^^32-1. Therefore, for an int array, 
with 4 byte elements, the largest possible value is 2^^30-1.

So I think the article is wrong. I don't think there is a bug in 
the code.