Repository navigation
Windows Buffer.from v4.x: TypeError: hex is not a function #8053
Description
Activity
node v4 doesn't have the new
Buffer.from()/Buffer.alloc()/etc. API yet.Reacted by Evgenia Karunus- addedbufferIssues and PRs related to the buffer subsystem.Issues and PRs related to the buffer subsystem.
on Aug 10, 2016 /cc @nodejs/lts @nodejs/buffer
Yes, but it seems to have some sort of undocumented
Buffer.from()that prevents a proper polyfill from being used.This should be sufficient, but it doesn't work because
Buffer.fromalready exists:function newBuffer(data, encoding, len) { return new Buffer(data, encoding, len); } if (!Buffer.from) { Buffer.from = newBuffer; } try { Buffer.from('1337', 'hex'); } catch(e) { // wish I could do something here to fix the broken Buffer.from try { Buffer.from = newBuffer; } catch(e) { // but alas, I cannot } }
See https://github.com/Daplie/node-buffer-v6-shim/blob/master/index.js#L25
Reacted by Yanming Jing@coolaj86 It’s not undocumented, it’s just inherited from the superclass:
> Buffer.from === Uint8Array.from true
I’d say this is a bug in the shim.
How should one polyfill between deprecated v4 and the new v6?
And on that note, v6 buf.buffer is not a proper
ArrayBuffer.var arr = new Uint8Array([1, 3, 5, 9, 17]); arr.buffer; // ArrayBuffer { byteLength: 5 } arr[0]; // 1 arr = new Uint8Array(arr.buffer); arr[0]; // 1 var buf = new Buffer([1, 3, 5, 9, 17]); buf.buffer; // ArrayBuffer { byteLength: 8192 } buf[0]; // 1 arr = new Uint8Array(buf.buffer); arr[0]; // 0
But perhaps I need to search and see if there's already an issue for that.
Update: found one #6744
The new Buffer constructor APIs are being backported and will be available in v4.5.0
@coolaj86 I’d say you can just check for
Buffer.from === Uint8Array.fromin the shim.Also, yes, it’s normal that multiple
Bufferinstances share a singleArrayBufferfor performance, it’s not really considered a bug. You can useBuffer.allocUnsafeSlow()if you need a completely independentBuffer.Knowing that it's a
Uint8Arraydoesn't help because it throws an exception when assigning to overwrite it. Unless I'm wrong and I was actually on v6 by mistake when I tested that.But knowing that it's getting backported in v4.5 satisfies my concern.
Thanks
I've got multiple Windows users complaining (see https://github.com/Daplie/rsa-compat.js/issues/9) on various versions of v4.x that they get an error
TypeError: hex is not a functionwith the following code:The buffer-v6-shim polyfill won't work because
Buffer.fromexists and is write-only and I can't reliably detect that it doesn't work other than withtry {} catch (e) {}, but again, becauseBuffer.fromis write-only, it can't be polyfilled with the fix.No reported problems in v6 or on other OSes (yet).