4 ms·

Oh good it's only been about 90 days since the last major API change to Buffer that's going to break my fine-tuned code once again. Luckily for me, it's going t

Oh good it's only been about 90 days since the last major API change to Buffer that's going to break my fine-tuned code once again. Luckily for me, it's going to require even more complex testing and launching to take advantage of zero'd out memory... javascript fatigue indeed.

joshmanders 11y ago
Yeah because screw security, right? I'm hella fatigued too! Did you even read the article or just blast out your opinion reading the title? > With these changes, you may be wondering what is going to happen to the existing Buffer() constructor. The answer is simple: nothing much. This pull request adds a note to the documentation that the existing Buffer() constructors have been deprecated however the constructor will continue to operate without any changes. In Node.js core terms we call this a “soft deprecation” or “docs only deprecation”. Existing code that uses the Buffer() constructor will continue to operate as it has before.
- officialchicken 11y ago
  Conjecture much? Or do you just like to copypasta articles and not actually provide an argument. Often, when writing extremely high-performance code, you give up security (and rely on higher-level contexts, like jails) A stable API and one that should have had the zero-out feature to begin with would have been a better response to my statement.
CJefferson 11y ago
Actually, this (to me) looks like a good change. I assume many people's code is having problem with uninitialised memory. If your code worked before, it will still work now with no changes, and in practice I've rarely noticed zeroing a buffer causing any measurable overhead (zeroing is so cheap compared to the cost of then filling the buffer anyway. In fact, it can be cheaper to zero, because there is no need to read the old stale values from memory into cache). There is also a new better designed interface, but the old one still works fine. I can't really imagine a better change.
- PeCaN 11y ago
  Actually, there's often no cost at all to allocating a zeroed buffer. FreeBSD zeroes out free memory in its idle time and uses that for calloc(). Linux hands out a pointer to a shared read-only page of zero memory and then gives you "real" memory when you write to it. I suspect NT does something like Linux, but I don't think its precise [mc]alloc() implementation is documented.
dsp1234 11y ago
even more complex testing and launching to take advantage of zero'd out memory I'm very curious to know what code would break with using zero'd out memory vs uninitialized buffers. Seems like there are few use cases where uninitialized buffers are actually desirable.
PeCaN 11y ago
So... does your code currently break if you just happen to get zeroed-out memory from the OS? (FreeBSD for example runs a background process every once in a while to zero out free blocks, mostly for purposes of calloc() but it's definitely not impossible Node would happen to get one of those even before this change.)
ebbv 11y ago
What? First of all the old constructor will continue to work as noted in the blog post. Secondly, what kind of terrible code did you write that can't handle zero-initialized memory?
- officialchicken 11y ago
  The kind that re-uses buffers and copies them... what did you think?

joshmanders 11y ago

Yeah because screw security, right? I'm hella fatigued too! Did you even read the article or just blast out your opinion reading the title? > With these changes, you may be wondering what is going to happen to the existing Buffer() constructor. The answer is simple: nothing much. This pull request adds a note to the documentation that the existing Buffer() constructors have been deprecated however the constructor will continue to operate without any changes. In Node.js core terms we call this a “soft deprecation” or “docs only deprecation”. Existing code that uses the Buffer() constructor will continue to operate as it has before.

officialchicken 11y ago
Conjecture much? Or do you just like to copypasta articles and not actually provide an argument. Often, when writing extremely high-performance code, you give up security (and rely on higher-level contexts, like jails) A stable API and one that should have had the zero-out feature to begin with would have been a better response to my statement.

CJefferson 11y ago

Actually, this (to me) looks like a good change. I assume many people's code is having problem with uninitialised memory. If your code worked before, it will still work now with no changes, and in practice I've rarely noticed zeroing a buffer causing any measurable overhead (zeroing is so cheap compared to the cost of then filling the buffer anyway. In fact, it can be cheaper to zero, because there is no need to read the old stale values from memory into cache). There is also a new better designed interface, but the old one still works fine. I can't really imagine a better change.

PeCaN 11y ago
Actually, there's often no cost at all to allocating a zeroed buffer. FreeBSD zeroes out free memory in its idle time and uses that for calloc(). Linux hands out a pointer to a shared read-only page of zero memory and then gives you "real" memory when you write to it. I suspect NT does something like Linux, but I don't think its precise [mc]alloc() implementation is documented.

dsp1234 11y ago

even more complex testing and launching to take advantage of zero'd out memory I'm very curious to know what code would break with using zero'd out memory vs uninitialized buffers. Seems like there are few use cases where uninitialized buffers are actually desirable.

PeCaN 11y ago

So... does your code currently break if you just happen to get zeroed-out memory from the OS? (FreeBSD for example runs a background process every once in a while to zero out free blocks, mostly for purposes of calloc() but it's definitely not impossible Node would happen to get one of those even before this change.)

ebbv 11y ago

What? First of all the old constructor will continue to work as noted in the blog post. Secondly, what kind of terrible code did you write that can't handle zero-initialized memory?

officialchicken 11y ago
The kind that re-uses buffers and copies them... what did you think?