Fix Issue 9126 - parse!int fails on size_t.max+1 digits long input (overflow)

[NilsBossung]

http://d.puremagic.com/issues/show_bug.cgi?id=9126
Could have seen this eleven months ago (#396) ...
I'm hesitating to add the test case, because it eats much time to test for a trivial bug.

[alexrp]

Well, we need some kind of test case to avoid a regression... why is adding one a problem?

[NilsBossung]

The problem is, the running time of the tests explodes (from under 1 second to over 5 minutes on my machine).

[jmdavis]

dmd is extremely inefficient when dealing with large array literals, and regardless, if you really have an array of length size_t.max, the memory requirements are going to be quite large, and the GC is going to kill all performance, making testing such a thing essentially infeasible.

That being said, I'm not sure that there's much point in caring about arrays that long. Things go wrong in general when you reach arrays that large. Overflow is bound to happen on a calculation somewhere and screw you over. I would expect things to go wrong with arrays that large. However, if we have an easy fix that makes them less error-prone, I see nothing wrong with that.

[jmdavis]

Merged.

[braddr]

Wait.. why does it parse anywhere NEAR enough characters to take noticable time? The destination type overflows after so few characters that time shouldn't be a factor. Parsing past overflow of the destination is pretty pointless.

[jmdavis]

Wait.. why does it parse anywhere NEAR enough characters to take noticable time? The destination type overflows after so few characters that time shouldn't be a factor. Parsing past overflow of the destination is pretty pointless.

Good point. The fact that it doesn't implies that something else is going on here. As far as I can tell, these changes do indeed make it so that if you exceed size_t.max, it'll work properly, but I have no idea why it would ever reach that point if it's watching for overflow as it should.

[NilsBossung]

Am Sonntag, 9. Dezember 2012, 18:26:45 schrieb Brad Roberts:

Wait.. why does it parse anywhere NEAR enough characters to take noticable
time? The destination type overflows after so few characters that time
shouldn't be a factor. Parsing past overflow of the destination is pretty
pointless.

Consider (a lot of) leading zeros. See the bug report for a test case.