[Prelim patch] Speed up ints parsing

[Paolo Carlini]

Loren James Rittle wrote:

>> ... and the results for sync_with_stdio(false); are even more
>> impressing (the num_get component is more relevant in this
>> case): [...performance numbers...]
>
> Paolo, sweet!

Thanks. Indeed, I'm quite happy with the performance of the final result.

> What sort of functionality testing have you done? Last
> I looked, our test suite doesn't run through many corner cases on
> numeric input esp. system-specific cases.

Right. However, for floats the situation is definitely more critical.
I did many additional tests, which allowed me to catch those two bugs
that I mentioned in a follow up message.

The most tricky point is that about overflow, but I can give a rough
proof that the code is correct, if you want. It goes more or less like
this (let's consider the positive case, the code for the negative case
is completely symmetrical): let's start from a non-overflow condition,
__result <= __max, as always is at the beginning of the loop. Therefore
the else branch is taken and __overflow remains false. Inside the 
branch, __result * __base can be at most numeric_limits::max() and, if 
we add __digit, a possible overflow would lead to a "wrap around" in the
computation of __new_result of not more than __digit. This means that 
the next check 'if (__result) __overflow |= __overflow <= __result, is 
definitely able to always catch the overflow condition and set the 
__overflow boolean accordingly. From now on, __overflow can only stay 
true and nothing else really matters (besides some speed in the code ;).

That said, I will keep on carrying out tests, some today too: in fact
I'm going to add some tests in fact, in the occasion of a clean up.

> Also, there used to be a
> claim that we wanted to use libc for such input to match per-system
> quirks.

I think that there are not that many quirks in the case of integers
(vs floats!), numeric_limits<> taken into account, of course!

Paolo.