Summary: | Performance tweak to parseInt | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Gavin Barraclough <barraclough> | ||||
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | darin, oliver, shinyak | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Bug Depends on: | 65366 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Gavin Barraclough
2011-07-28 10:30:26 PDT
Shouldn’t it be <= INT_MAX rather than < INT_MAX? Should we be using a constant instead of INT_MAX? Could we use unsigned instead of int to cover a slightly larger range? > Shouldn’t it be <= INT_MAX rather than < INT_MAX? > Should we be using a constant instead of INT_MAX? This should probably be < (INT_MAX + 1), will fix this & use a constant. > Could we use unsigned instead of int to cover a slightly larger range? Unsigned doesn't buy us much coverage, and makes the jsNumber conversion slightly more expensive (we'll have to check we're in the int32 range & potentially generate a boxed double), so I probably won't do this. I'd go to int64_t if this bought us the whole 10^21 range, but sadly not. Created attachment 102433 [details]
Patch
Oops! I have mistaken to upload the patch to the wrong place...!! Please ignore it and remove the patch. |