On 2011/11/21 14:27:35, Yang wrote:
Please take a look.
This patch adds a guard against non-string subjects when executing regexp
in
generated code, something that would only happen if the native function is
called with unsafe arguments. The price is that sliced string subjects are
handled m
I'm not sure this is the correct place to put the safeguard.
If nothing else, it should be earlier in the function, not after doing other
tests that expect a string.
http://codereview.chromium.org/8554004/diff/1/src/arm/code-stubs-arm.cc
File src/arm/code-stubs-arm.cc (right):
http://codereview
On 2011/11/24 09:31:57, Lasse Reichstein wrote:
I'm not sure this is the correct place to put the safeguard.
If nothing else, it should be earlier in the function, not after doing
other
tests that expect a string.
If the subject is not a string, it would have kIsNotStringTag set and the
te
The previous checks indeed, subtly, include the kNotStringTag bit in the
comparison, and should be safe. If doing it this way, at least put a comment
explaining that the lt(r1, ...) comparison can't succeed if the object is a
non-string.
Apart from that, the optimal (IMO) place to check for the i
I considered putting the check into EmitRegExpExec, but a type check there
would be a lot more expensive since the instance type would have to be
loaded. In the stub however we have to fetch the instance type anyways, so
it is a lot cheaper there.
Yang
On Thu, Nov 24, 2011 at 6:08 PM, wrote:
>
