Some questions about buffer doc
- Version: 7.2.0
- Platform: Windows 7 x64
- Subsystem: doc, buffer
I'm preparing a PR with some small fixes in code examples of the buffer doc and I've stumbled on some puzzles I want to clarify before the PR.
-
buf.lastIndexOf()
byteOffset
argument explanation.
What does the "(not inclusive)" remark actually mean? In this code (not in the doc) the byteOffset
seems to be inclusive in the search and the result.
console.log(Buffer.from('0123').lastIndexOf('1', 1));
1
The same for this code in the doc:
Buffer.from('this buffer is a buffer');
// Prints: 5
console.log(buf.lastIndexOf('buffer', 5));
So the question is this one: should this remark be clarified more or should it be removed?
-
new Buffer(size)
andBuffer.allocUnsafe(size)
examples.
It happens that the actual outputs of these fragments do not match with described ones for me for most of the tests:
const buf = new Buffer(5);
// Prints: (contents may vary): <Buffer 78 e0 82 02 01>
console.log(buf);
buf.fill(0);
// Prints: <Buffer 00 00 00 00 00>
console.log(buf);
const buf = Buffer.allocUnsafe(5);
// Prints: (contents may vary): <Buffer 78 e0 82 02 01>
console.log(buf);
buf.fill(0);
// Prints: <Buffer 00 00 00 00 00>
console.log(buf);
While they do output as described in the REPL, tested by script files they output the same lines in some circumstances:
<Buffer 00 00 00 00 00>
<Buffer 00 00 00 00 00>
After some research, I've found out there is a rather strong correlation between script file size and zeroing of a buffer beginning. If the before mentioned fragments are saved in 105-176 bytes file size (adjusted by these changes: ASCII/UTF-8, +/- BOM, +/- comments/space), the first 5 bytes are almost always empty. So I've written a weird script to find out more about this correlation. Here are some notes about results:
a. Zeroing scheme of buffer bytes is the same inside cycles of a script file size increasing by 8 bytes.
b. Correlation is flaky, so the statistics data need to be averaged in the research script and manually filtered after the tests.
c. Buffer.alloc(size)
always works safely as intended (the stat log is empty, i.e. no non-zero bytes schemes are detected and saved).
d. Buffer.allocUnsafeSlow(size)
also has some correlation, but it is significantly flakier and does not make big zero fragments in the buffer beginning, so it could be ignored in this case.
If somebody is interested in the research code, here is the script. In the comments there, I also give the stat data from a test run on my machine. The stat data format is "script file size: scheme with non-zero bytes indexes in created buffers". Repeated lines inside 8-bytes cycles are filtered. If some flaky case happens inside this cycles, it is marked by *
at the beginning of the line. Here is also the diff between new Buffer(size)
and Buffer.allocUnsafe(size)
stats.
So the question is this one: is this correlation depends on some hardware/software features or is it something stable? In the first case, it could be ignored, in the second case the code examples should be adjusted to fall out of size diapasons that produce big zero fragments at the beginning or buffers, otherwise, novices could be confused by these examples if they run them by themselves.
Sorry for my bad English and all the possible obscurity.