
Node.js Buffer API Changes - joshmanders
https://medium.com/@jasnell/node-js-buffer-api-changes-3c21f1048f97#.ol2veacwu
======
Matthias247
I don't think adding more explicit constructors and choices regarding
initialization is a bad thing. But seriously - passing arbitrary objects
parsed from JSON to a constructor?!? If someone is really doing that then the
problems might be bigger then whether there is some uninitialized memory or
not.

------
officialchicken
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
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
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.

