Skip to content
This repository has been archived by the owner on Sep 9, 2024. It is now read-only.

Byte Array >= 256 length is accepted, why? #13

Open
bryc opened this issue Jan 23, 2017 · 1 comment
Open

Byte Array >= 256 length is accepted, why? #13

bryc opened this issue Jan 23, 2017 · 1 comment

Comments

@bryc
Copy link

bryc commented Jan 23, 2017

When first using this library I used a plain array as input: XXH.h64(Array(256).fill(0), 0).toString(16), which appeared to work fine.

But it appears that only ArrayBuffer and strings are supported, which makes it odd that arrays still worked. However for some strange reason if the length of the array is 255 or below, an error occurs:

> XXH.h64(Array(255).fill(0), 0).toString(16)

VM359:2 Uncaught TypeError: t.copy is not a function
at h.update (:2:8060)
at Object.h [as h64] (:2:3366)
at :1:5

I didn't notice this because my inputs were exactly 256 or higher.

I can of course switch to using something like XXH.h64(new Uint8Array([]).buffer, 0).toString(16), but I think it is worth mentioning this quirk.

Also, if the seed argument is omitted ( XXH.h64(Array(256).fill(0)).toString(16)), the output is "[object Object]", not exactly an error indicating that a default value isn't being used.

@pierrec
Copy link
Owner

pierrec commented Jan 25, 2017

Indeed, Array is currently not supported. Pull requests are welcome :) as I dont have time right now to work on this.

The fact that it worked for an array of size 256 is due to the way the algorithm works. It can actually work for some other values too. It does not hit the path where .copy() is used.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants