writeFloat* and writeDouble* do no longer throw range error when out of bounds

I'l let the code speak for itself.

"use strict";

let buffer;

buffer = new Buffer(8);
buffer.fill(1);
console.log(buffer.writeFloatLE(0, 4), buffer, buffer.length);
// Node.js v4.3.1: "8 <Buffer 01 01 01 01 00 00 00 00> 8"
// Node.js v5.7.1: "8 <Buffer 01 01 01 01 00 00 00 00> 8"

buffer = new Buffer(8);
buffer.fill(1);
try {
    console.log(buffer.writeFloatLE(0, 5), buffer, buffer.length);
    // Node.js v5.7.1: "9 <Buffer 01 01 01 01 01 00 00 00> 8"
} catch (error) {
    console.log(error);
    // Node.js v4.3.1: "[RangeError: index out of range]"
}

buffer = new Buffer(16);
buffer.fill(1);
console.log(buffer.writeDoubleLE(0, 8), buffer, buffer.length);
// Node.js v4.3.1: "16 <Buffer 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00> 16"
// Node.js v5.7.1: "16 <Buffer 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00> 16"

buffer = new Buffer(16);
buffer.fill(1);
try {
    console.log(buffer.writeDoubleLE(0, 9), buffer, buffer.length);
    // Node.js v5.7.1: "17 <Buffer 01 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00> 16"
} catch (error) {
    console.log(error);
    // Node.js v4.3.1: "[RangeError: index out of range]"
}

System 1

• Version: v4.3.1
• Platform: Windows Server 2012 R2 64-bit
• Subsystem: Buffer

System 2

• Version: v5.7.1
• Platform: Windows 7 Pro SP1 64-bit
• Subsystem: Buffer

[princejwesley]

this commit introduces silent drop behaviour.

I do not pass noAssert.

According to the docs of writeDouble*:

...Set noAssert to true to skip validation of value and offset. This means that value may be too large for the specific function and offset may be beyond the end of the Buffer leading to the values being silently dropped. This should not be used unless you are certain of correctness....

After reading this, i expect it to not silently drop because i did not pass noAssert so it defaults to false.

[Fishrock123]

cc @trevnorris

[princejwesley]

@Ravoltz Setting noAssert to true is to skip validation. Negative sentence hurts.

[targos]

The regression appeared between v5.1.1 and v5.2.0

[targos]

I suspect fcf0e8e

[targos]

Confirmed with git bisect.
cc @matthewloring

[matthewloring]

The commit linked by @princejwesley introduces the behavior where, if there would be overflow, we instead copy as much of the value as possible without overflowing. The check to see whether range errors should be thrown should occur above this failsafe logic. I'll put together a PR with this change.