@@ -52,53 +52,53 @@ In versions of Node.js prior to 6.0.0, `Buffer` instances were created using the
52
52
` Buffer ` constructor function, which allocates the returned ` Buffer `
53
53
differently based on what arguments are provided:
54
54
55
- * Passing a number as the first argument to ` Buffer() ` (e.g. ` new Buffer(10) ` ),
55
+ * Passing a number as the first argument to ` Buffer() ` (e.g. ` new Buffer(10) ` )
56
56
allocates a new ` Buffer ` object of the specified size. Prior to Node.js 8.0.0,
57
57
the memory allocated for such ` Buffer ` instances is * not* initialized and
58
58
* can contain sensitive data* . Such ` Buffer ` instances * must* be subsequently
59
59
initialized by using either [ ` buf.fill(0) ` ] [ `buf.fill()` ] or by writing to the
60
- ` Buffer ` completely. While this behavior is * intentional* to improve
61
- performance, development experience has demonstrated that a more explicit
62
- distinction is required between creating a fast-but-uninitialized ` Buffer `
63
- versus creating a slower-but-safer ` Buffer ` . Starting in Node.js 8.0.0,
64
- ` Buffer(num) ` and ` new Buffer(num) ` will return a ` Buffer ` with initialized
65
- memory.
60
+ entire ` Buffer ` . While this behavior is * intentional* to improve performance,
61
+ development experience has demonstrated that a more explicit distinction is
62
+ required between creating a fast-but-uninitialized ` Buffer ` versus creating a
63
+ slower-but-safer ` Buffer ` . Starting in Node.js 8.0.0, ` Buffer(num) ` and
64
+ ` new Buffer(num) ` will return a ` Buffer ` with initialized memory.
66
65
* Passing a string, array, or ` Buffer ` as the first argument copies the
67
66
passed object's data into the ` Buffer ` .
68
67
* Passing an [ ` ArrayBuffer ` ] or a [ ` SharedArrayBuffer ` ] returns a ` Buffer ` that
69
68
shares allocated memory with the given array buffer.
70
69
71
70
Because the behavior of ` new Buffer() ` is different depending on the type of the
72
- first argument, security and reliability issues can be inadvertantly introduced
73
- into applications when argument validation or ` Buffer ` initialization are not
71
+ first argument, security and reliability issues can be inadvertently introduced
72
+ into applications when argument validation or ` Buffer ` initialization is not
74
73
performed.
75
74
76
- To make the creation of ` Buffer ` instances more reliable and less error prone,
75
+ To make the creation of ` Buffer ` instances more reliable and less error- prone,
77
76
the various forms of the ` new Buffer() ` constructor have been ** deprecated**
78
77
and replaced by separate ` Buffer.from() ` , [ ` Buffer.alloc() ` ] , and
79
78
[ ` Buffer.allocUnsafe() ` ] methods.
80
79
81
80
* Developers should migrate all existing uses of the ` new Buffer() ` constructors
82
81
to one of these new APIs.*
83
82
84
- * [ ` Buffer.from(array) ` ] returns a new ` Buffer ` containing a * copy* of the provided
85
- octets.
83
+ * [ ` Buffer.from(array) ` ] returns a new ` Buffer ` that * contains a copy* of the
84
+ provided octets.
86
85
* [ ` Buffer.from(arrayBuffer[, byteOffset [, length]]) ` ] [ `Buffer.from(arrayBuffer)` ]
87
- returns a new ` Buffer ` that * shares* the same allocated memory as the given
86
+ returns a new ` Buffer ` that * shares the same allocated memory* as the given
88
87
[ ` ArrayBuffer ` ] .
89
- * [ ` Buffer.from(buffer) ` ] returns a new ` Buffer ` containing a * copy* of the
88
+ * [ ` Buffer.from(buffer) ` ] returns a new ` Buffer ` that * contains a copy* of the
90
89
contents of the given ` Buffer ` .
91
- * [ ` Buffer.from(string[, encoding]) ` ] [ `Buffer.from(string)` ] returns a new ` Buffer `
92
- containing a * copy* of the provided string.
93
- * [ ` Buffer.alloc(size[, fill[, encoding]]) ` ] [ `Buffer.alloc()` ] returns a "filled"
94
- ` Buffer ` instance of the specified size. This method can be significantly
95
- slower than [ ` Buffer.allocUnsafe(size) ` ] [ `Buffer.allocUnsafe()` ] but ensures
96
- that newly created ` Buffer ` instances never contain old and potentially
97
- sensitive data .
90
+ * [ ` Buffer.from(string[, encoding]) ` ] [ `Buffer.from(string)` ] returns a new
91
+ ` Buffer ` that * contains a copy* of the provided string.
92
+ * [ ` Buffer.alloc(size[, fill[, encoding]]) ` ] [ `Buffer.alloc()` ] returns a new
93
+ initialized ` Buffer ` of the specified size. This method is slower than
94
+ [ ` Buffer.allocUnsafe(size) ` ] [ `Buffer.allocUnsafe()` ] but guarantees that newly
95
+ created ` Buffer ` instances never contain old data that is potentially
96
+ sensitive.
98
97
* [ ` Buffer.allocUnsafe(size) ` ] [ `Buffer.allocUnsafe()` ] and
99
98
[ ` Buffer.allocUnsafeSlow(size) ` ] [ `Buffer.allocUnsafeSlow()` ] each return a
100
- new ` Buffer ` of the specified ` size ` whose content * must* be initialized
101
- using either [ ` buf.fill(0) ` ] [ `buf.fill()` ] or written to completely.
99
+ new uninitialized ` Buffer ` of the specified ` size ` . Because the ` Buffer ` is
100
+ uninitialized, the allocated segment of memory might contain old data that is
101
+ potentially sensitive.
102
102
103
103
` Buffer ` instances returned by [ ` Buffer.allocUnsafe() ` ] * may* be allocated off
104
104
a shared internal memory pool if ` size ` is less than or equal to half
@@ -117,7 +117,7 @@ force all newly allocated `Buffer` instances created using either
117
117
this flag * changes the default behavior* of these methods and * can have a significant
118
118
impact* on performance. Use of the ` --zero-fill-buffers ` option is recommended
119
119
only when necessary to enforce that newly allocated ` Buffer ` instances cannot
120
- contain potentially sensitive data .
120
+ contain old data that is potentially sensitive.
121
121
122
122
``` txt
123
123
$ node --zero-fill-buffers
0 commit comments