js_strtod/js_strtointeger callers eat OOM

NEW
Unassigned

Status

()

Core
JavaScript Engine
8 years ago
9 months ago

People

(Reporter: bz, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

js_strtod returns false to indicate OOM.  Currently various callers (esp. off trace) just eat that exception.

We only end up with OOM due to heap-allocating a buffer to pass to strtod.  We could try limiting string lengths and using a stack buffer or we could templatize strtod to work on jschar, possibly.
From bug 551118 comment 4:

"I was thinking we could make js_strtod infallible and use jsdouble as its
return type for better perf, if we avoid malloc'ing a buffer for really long
strings, instead using some generous stack buffer (128 chars? big enough by far
for any sane numeric strings), and if the length is too big to fit, we
pre-parse the string to see whether it is well-formed. The RegExp for doubles
is easy enough to implement by hand in C++:

/^\d+\.\d*(?:[eE][-+]?\d+)?|^\d+(?:\.\d*)?[eE][-+]?\d+|^\.\d+(?:[eE][-+]?\d+)?/

What the pre-parse pass would do would be throw away insignificant trailing
digits (ones that cannot possibly cause rounding to go differently from when
those digits are dropped), but of course do no conversion.

/be"

---

The bit about discarding trailing digits was for the fraction only, of course. Overlarge exponent and mantissa would have to be clamped to the correctly signed infinity. There might be other gotchas -- IIRC string to double requires bignums in order to round decimal properly when converting to binary, so this idea may not work.

/be
(Assignee)

Updated

4 years ago
Assignee: general → nobody

Updated

9 months ago
See Also: → bug 1370531
You need to log in before you can comment on or make changes to this bug.