buffer: coerce slice parameters consistenly by thefourtheye · Pull Request #9101

buffer: coerce slice parameters consistenly by thefourtheye · Pull Request #9101 · nodejs/node

added the buffer

Issues and PRs related to the buffer subsystem.

label

Oct 14, 2016

As shown in nodejs#9096, the offset and
end value of the `slice` call are coerced to numbers and then passed to
`FastBuffer`, which internally truncates the mantissa part if the number
is actually a floating point number. This actually affects the new
length of the slice calculation. For example,

    > const original = Buffer.from('abcd');
    undefined
    > original.slice(original.length / 3).toString()
    'bc'

This happens because, starting value of the slice is 4 / 3, which is
1.33 (approximately). Now, the length of the slice is calculated as
the difference between the actual length of the buffer and the starting
offset. So, it becomes 2.67 (4 - 1.33). Now, a new `FastBuffer` is
constructed, with the following values as parameters,

 1. actual buffer object,
 2. starting value, which is 1.33 and
 3. the length 2.67.

The underlying C++ code truncates the numbers and they become 1 and 2.
That is why the result is just `bc`.

This patch makes sure that all the offsets are coerced to integers
before any calculations are done.

Fixes: nodejs#9096

jasnell pushed a commit that referenced this pull request

Oct 18, 2016

As shown in #9096, the offset and
end value of the `slice` call are coerced to numbers and then passed to
`FastBuffer`, which internally truncates the mantissa part if the number
is actually a floating point number. This actually affects the new
length of the slice calculation. For example,

    > const original = Buffer.from('abcd');
    undefined
    > original.slice(original.length / 3).toString()
    'bc'

This happens because, starting value of the slice is 4 / 3, which is
1.33 (approximately). Now, the length of the slice is calculated as
the difference between the actual length of the buffer and the starting
offset. So, it becomes 2.67 (4 - 1.33). Now, a new `FastBuffer` is
constructed, with the following values as parameters,

 1. actual buffer object,
 2. starting value, which is 1.33 and
 3. the length 2.67.

The underlying C++ code truncates the numbers and they become 1 and 2.
That is why the result is just `bc`.

This patch makes sure that all the offsets are coerced to integers
before any calculations are done.

Fixes: #9096
PR-URL: #9101
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>

jasnell pushed a commit that referenced this pull request

Oct 18, 2016

As shown in #9096, the offset and
end value of the `slice` call are coerced to numbers and then passed to
`FastBuffer`, which internally truncates the mantissa part if the number
is actually a floating point number. This actually affects the new
length of the slice calculation. For example,

    > const original = Buffer.from('abcd');
    undefined
    > original.slice(original.length / 3).toString()
    'bc'

This happens because, starting value of the slice is 4 / 3, which is
1.33 (approximately). Now, the length of the slice is calculated as
the difference between the actual length of the buffer and the starting
offset. So, it becomes 2.67 (4 - 1.33). Now, a new `FastBuffer` is
constructed, with the following values as parameters,

 1. actual buffer object,
 2. starting value, which is 1.33 and
 3. the length 2.67.

The underlying C++ code truncates the numbers and they become 1 and 2.
That is why the result is just `bc`.

This patch makes sure that all the offsets are coerced to integers
before any calculations are done.

Fixes: #9096
PR-URL: #9101
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>

jasnell pushed a commit that referenced this pull request

Oct 19, 2016

As shown in #9096, the offset and
end value of the `slice` call are coerced to numbers and then passed to
`FastBuffer`, which internally truncates the mantissa part if the number
is actually a floating point number. This actually affects the new
length of the slice calculation. For example,

    > const original = Buffer.from('abcd');
    undefined
    > original.slice(original.length / 3).toString()
    'bc'

This happens because, starting value of the slice is 4 / 3, which is
1.33 (approximately). Now, the length of the slice is calculated as
the difference between the actual length of the buffer and the starting
offset. So, it becomes 2.67 (4 - 1.33). Now, a new `FastBuffer` is
constructed, with the following values as parameters,

 1. actual buffer object,
 2. starting value, which is 1.33 and
 3. the length 2.67.

The underlying C++ code truncates the numbers and they become 1 and 2.
That is why the result is just `bc`.

This patch makes sure that all the offsets are coerced to integers
before any calculations are done.

Fixes: #9096
PR-URL: #9101
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>

cjihrig added a commit to cjihrig/node that referenced this pull request

Nov 5, 2016

This is a partial revert of
14d1a8a, which coerced the offset
of Buffer#slice() using the | operator. This causes some edge
cases to be handled incorrectly. This commit restores the old
behavior, but converts offsets to integers using Math.trunc().
This commit does not revert any tests, and adds an additional
regression test.

Refs: nodejs#9096
Refs: nodejs#9101
PR-URL: nodejs#9341
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>

evanlucas pushed a commit that referenced this pull request

Nov 7, 2016