On 17.5.2013. 0:23, Marco Leise wrote:
Am Thu, 16 May 2013 22:39:16 +0200
schrieb luka8088<[email protected]>:
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.
