[whatwg] Cryptographically strong random numbers
brendan at mozilla.com
Wed Feb 16 17:37:56 PST 2011
On Feb 16, 2011, at 5:33 PM, Allen Wirfs-Brock wrote:
> On Feb 16, 2011, at 4:54 PM, David Herman wrote:
>> I say: let's make it typed array in the short term, but TC39 will spec it as an array of uint32 according to the binary data spec. We will try to make the binary data spec as backwards compatible as possible with typed arrays anyway. So in the near term, implementors can use typed arrays, but when they have implementations of the full binary data spec, they can change to use those. It'll probably be a slightly backwards-incompatible change, but by keeping them relatively API-compatible, it shouldn't make too much difference in practice. Plus we can warn people that that change is coming.
> Dave, most browsers other than FF4 internally box all integers with with 32-significant bits.
I'm not sure this is still true. Certainly on x64, but also on x86, NaN-boxing has taken over in many VMs.
> Some may box with 31 or even 30 significant bits. So if we spec. the value as a uint32 and (they are truly random enough) then at least half and possible 75% or more of the values in the array will be boxed in many browsers. Such boxing will have a much higher cost than immediate uint16 values. That's why I propose 16-bit values.
Given the implementors on es-discuss, we should survey first. I'd hate to prematurely (de-)optimize.
I agree with David Wagner that the API has to be dead-simple, and it seems to me having only 16-bit values returned in a JS array may tend to result in more bit-mixing bugs than if we used 32-bit elements, if programmers are carelessly porting code that was written for uint32 arrays.
More information about the es-discuss