You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you pass a <Uint8Array> as the fill to Buffer.alloc(size[, fill[, encoding]]) node (v14.15.1) will copy those bytes verbatim into the buffer, whereas with the ferros/buffer package, it does something and the end result is that the resulting buffer is filled with strange data.
I'd perhaps PR a fix for this specific issue, but I feel like the real problem is that this package needs to be refreshed with the latest buffer code + tests from node, rather than me patching in a specific fix? i.e. Perhaps related to #177. I looked into this briefly and the transform from node looked non-trivial if you haven't done it before.
The text was updated successfully, but these errors were encountered:
timoxley
added a commit
to streamr-dev/streamr-client-protocol-js
that referenced
this issue
Dec 8, 2020
Hi @feross!
If you pass a
<Uint8Array>
as thefill
toBuffer.alloc(size[, fill[, encoding]])
node (v14.15.1) will copy those bytes verbatim into the buffer, whereas with theferros/buffer
package, it does something and the end result is that the resulting buffer is filled with strange data.It works fine for numbers between 0 and 127, but things get weird once you're out of those bounds (Uint8 should work for numbers between 0 - 255).
Workaround is to pass a
Buffer
as thefill
value:I'd perhaps PR a fix for this specific issue, but I feel like the real problem is that this package needs to be refreshed with the latest buffer code + tests from node, rather than me patching in a specific fix? i.e. Perhaps related to #177. I looked into this briefly and the transform from node looked non-trivial if you haven't done it before.
The text was updated successfully, but these errors were encountered: