Summary: | Implement Number.prototype.clz() | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Dániel Bátyai <dbatyai.u-szeged> | ||||||
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | commit-queue, ggaren, oliver, sam, syoichi | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Dániel Bátyai
2014-02-28 03:27:44 PST
Created attachment 225453 [details]
Proposed patch
Comment on attachment 225453 [details] Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=225453&action=review > Source/JavaScriptCore/runtime/NumberPrototype.cpp:472 > + int zeroCount = 0; > + for (int i = 31; i >= 0; i--) { > + if (!(number >> i)) > + zeroCount++; > + else > + break; > + } > + return JSValue::encode(jsString(exec, String::numberToStringECMAScript(zeroCount))); I think this should be a separate function and also use __builtin_clz when building with compilers that support it (GCC, clang). Comment on attachment 225453 [details]
Proposed patch
Is coz really supposed to return a string? That seems impossible, given that its goal is performance.
*clz (In reply to comment #3) > (From update of attachment 225453 [details]) > Is [clz] really supposed to return a string? That seems impossible, given that its goal is performance. http://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.prototype.clz Seems like the answer is it is not supposed to return a string. Created attachment 225661 [details]
Proposed patch
Modified according to comments.
Unfortunately, __builtin_clz(0) was returning 31 instead of the 32 specified in the standard, so I had to add a check for that.
Comment on attachment 225661 [details] Proposed patch Clearing flags on attachment: 225661 Committed r165047: <http://trac.webkit.org/changeset/165047> All reviewed patches have been landed. Closing bug. |