Pop Quiz what is wrong with this code?

[Avrina]

On Sunday, 21 June 2020 at 19:33:47 UTC, Patrick Schluter wrote:
> On Sunday, 21 June 2020 at 13:17:54 UTC, Avrina wrote:
>> On Sunday, 21 June 2020 at 10:12:22 UTC, Patrick Schluter 
>> wrote:
>>> On Saturday, 20 June 2020 at 23:36:25 UTC, Avrina wrote:
>>>> On Saturday, 20 June 2020 at 18:15:27 UTC, Steven 
>>>> Schveighoffer wrote:
>>>>> On 6/20/20 12:00 PM, Danni Coy wrote:
>>>>>
>>>>>> I tried explicitly making x and y ints and I got a 
>>>>>> depreciation warning.
>>>>>
>>>>> foreach(ptrdiff_t y, ref row; offsetMap)
>>>>>
>>>>> is that what you wanted?
>>>>>
>>>>> ptrdiff_t is the signed version of size_t. The complaint is 
>>>>> not that you are converting from unsigned to signed, but 
>>>>> that you are converting from 64-bit to 32-bit.
>>>>>
>>>>> -Steve
>>>>
>>>> Why isn't that deprecated as well? implicitly converting 
>>>> from ulong to long is an error as much as ulong to uint.
>>>
>>> No. conversion of ulong to uint loses 32 times more data than 
>>> conversion to long does.
>>
>> Lol, it's not linear friend.
>
> losing 1 bit vs losing 32 bits. The exponentiation is 
> irrelevant.

It is when that 1 bit is worth 9223372032559808512

>> You lose around 18446744069414584319 values from ulong to 
>> uint, you lose 9223372032559808512 from ulong to long. Which 
>> is about 2 times less data. Which makes sense as it is 
>> basically 2^64 - 2^63, so of course it would only be x2 -- not 
>> x32.
>
>> Not that it should matter how much, it's a problem either way.
>
> But a much less severe one.
> Overflowing a 32 bit index on a 64 bit machine with the data 
> sizes that exist today (files of more than 4GiB are not rare, 
> zips, videos and databases).
> 9 223 372 032 559 808 512  is still 32768x bigger than 
> 281 474 976 710 656, the biggest addressable range on x86_64.

That's an index to an array, not a file. The File api uses ulong 
(as it should) and doesn't use size_t. If you are using memory 
mapped files, that isn't portable and you are going to have 
issues with performance. Otherwise a 32-bit index is sufficient, 
you aren't ever going to have an array that big that uses up that 
much memory in the system. So again, doesn't matter. There's a 
reason no one has complained about this "bug" for 20 years, and 
the only reason it was "discovered" was because it was 
inconsistent with foreach_reverse.