The behavior of Buffer#compare doesn't match its documentation

[benblank]

• Version: v6.12.2 (linux), v8.9.3 (linux, windows), v9.2.1 (linux)
• Platform (linux): Linux ubuntu 4.13.0-16-generic Multiple persistent child-process-related test failures on Windows when running as a Service #19-Ubuntu SMP Wed Oct 11 18:35:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
• Platform (windows): Windows 10 Home 64-bit (version 1703 build 15063.726)
• Subsystem: buffer

In the documentation for Buffer#compare, it's stated that the targetEnd, sourceStart, and sourceEnd parameters are each "ignored when targetStart is undefined". However, I do not observe that behavior on versions 6.12.2, 8.9.3, or 9.2.1. Instead, the following code fails the third assertion:

const assert = require('assert');

const foo = Buffer.from([0, 1, 2, 3]);
const bar = Buffer.from([1, 2, 3, 4]);

const LESS_THAN = -1;
const EQUAL = 0;

assert.equal(foo.compare(bar), LESS_THAN, 'Without indices, foo is less.');
assert.equal(foo.compare(bar, 0, 3, 1, 4), EQUAL, 'With indices which compare only the 1..3 from each buffer, foo and bar are equal.');
assert.equal(foo.compare(bar, undefined, 3, 1, 4), LESS_THAN, 'With targetStart undefined, all other indices should be ignored.');

Although both behaviors (ignoring or not ignoring subsequent parameters) seem reasonable, it looks like the discrepancy has always existed (see 473f086, which introduced the feature), so it probably makes more sense to change the docs.

[BridgeAR]

As far as I see it the "ignored" part is just interpreted differently. By setting the value to undefined, it is normal that it will fall back to the default value and not have any further impact on other arguments. So the behavior is correct as far as I see it. The wording might be improved though.

[Jedeu]

Hey I'd like to try and tackle this one please! Will look into it after work

[maclover7]

Fixed via #17796