primitive value overflow

[luka8088]

On 17.5.2013. 0:23, Marco Leise wrote:
> Am Thu, 16 May 2013 22:39:16 +0200
> schrieb luka8088<luka8088 at owave.net>:
>
>> On 16.5.2013. 22:29, Andrej Mitrovic wrote:
>>> On Thursday, 16 May 2013 at 20:24:31 UTC, luka8088 wrote:
>>>> Hello everyone.
>>>>
>>>> Today I ran into a interesting issue. I wrote
>>>>
>>>> auto offset = text1.length - text2.length;
>>>
>>> Yeah, I don't like these bugs either. In the meantime you can swap auto
>>> with 'sizediff_t' or 'ptrdiff_t', and then you can check if it's
>>> non-negative.
>>
>> Yes, thanks for the advice, I did something similar. =)
>
> Now that doesn't work if you deal with some text2 that is over
> 2 GiB longer than text1.
> My approach is to see the close relation between any offset
> from beginning or length to the machine memory model. So any
> byte or char array in memory naturally has an unsigned length
> typed by the architecture's word size (e.g. 32 or 64 bit).
> With that in mind I _only_ ever subtract two values if I know
> the difference will be positive. That is the case for
> file_size - valid_offset for example.
> I don't know the context for your line of code, but if text1
> and text2 are passed in as parameters to a function, a
> contract should verify that text1 is longer (or equal) than
> text2.
> Now feel free to tell me I'm wrong, but with the two lengths
> being natural numbers or "countable", I claim that a negative
> value for your offset variable would not have been usable
> anyway. It is a result that makes no sense. So on the next line
> you probably check "if (offset>= 0)" which is the same as
> putting "if (text1.length>= text2.length)" one line earlier
> to avoid running into the situation where you can end up with
> an over- or underflow because the result range of size_t -
> size_t fits neither size_t nor sizediff_t.
>
> Say text1 is 0 bytes long and text2 is 3_000_000_000 bytes
> long. Then -3_000_000_000 would be the result that cannot be
> stored in any 32-bit type. And thus it is important to think
> about possible input to your integer calculations and place
> if-else-branches there (or in-contracts), especially when the
> language accepts overflows silently.
> But I'd really like to see the context of your code if it is
> not a secret. :)
>

I understand perfectly the issue that you are pointing out. But that is 
not the real issue here. I know how computer arithmetic works, the 
understanding is not the issue here. The real issue is that at the time 
of writing unsigned was never mentioned, and it never came to my mind 
that it could be the issue (until I printed that actual value). So in 
reality I made a mistake, as I sometimes make a typo mistake. And I fix 
them (as I did this one) by debugging.

What I want to point out is that this kind of mistakes can be pointed 
out to the programer in debug mode (and save programer time) by adding a 
runtime check. The only real benefit here would be shorter debug time, 
and the only real tradeoff would be slower executing in debug mode. 
Nothing else.