Skip to content

Commit 8191ada

Browse files
Trotttargos
authored andcommitted
doc: improve Buffer() text
Rewording, punctuation, consistent sentence structure and italics, wrap section at 80 characters. PR-URL: #19567 Reviewed-By: Vse Mozhet Byt <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Gibson Fahnestock <[email protected]>
1 parent 2fadc9e commit 8191ada

File tree

1 file changed

+24
-24
lines changed

1 file changed

+24
-24
lines changed

doc/api/buffer.md

+24-24
Original file line numberDiff line numberDiff line change
@@ -52,53 +52,53 @@ In versions of Node.js prior to 6.0.0, `Buffer` instances were created using the
5252
`Buffer` constructor function, which allocates the returned `Buffer`
5353
differently based on what arguments are provided:
5454

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)`)
5656
allocates a new `Buffer` object of the specified size. Prior to Node.js 8.0.0,
5757
the memory allocated for such `Buffer` instances is *not* initialized and
5858
*can contain sensitive data*. Such `Buffer` instances *must* be subsequently
5959
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.
6665
* Passing a string, array, or `Buffer` as the first argument copies the
6766
passed object's data into the `Buffer`.
6867
* Passing an [`ArrayBuffer`] or a [`SharedArrayBuffer`] returns a `Buffer` that
6968
shares allocated memory with the given array buffer.
7069

7170
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
7473
performed.
7574

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,
7776
the various forms of the `new Buffer()` constructor have been **deprecated**
7877
and replaced by separate `Buffer.from()`, [`Buffer.alloc()`], and
7978
[`Buffer.allocUnsafe()`] methods.
8079

8180
*Developers should migrate all existing uses of the `new Buffer()` constructors
8281
to one of these new APIs.*
8382

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.
8685
* [`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
8887
[`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
9089
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.
9897
* [`Buffer.allocUnsafe(size)`][`Buffer.allocUnsafe()`] and
9998
[`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.
102102

103103
`Buffer` instances returned by [`Buffer.allocUnsafe()`] *may* be allocated off
104104
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
117117
this flag *changes the default behavior* of these methods and *can have a significant
118118
impact* on performance. Use of the `--zero-fill-buffers` option is recommended
119119
only when necessary to enforce that newly allocated `Buffer` instances cannot
120-
contain potentially sensitive data.
120+
contain old data that is potentially sensitive.
121121

122122
```txt
123123
$ node --zero-fill-buffers

0 commit comments

Comments
 (0)