[Medo-ID]

Fixes part of #35293 (Buffer#indexOf / lastIndexOf / includes).

This PR updates the Node Buffer search implementation to support the new end parameter introduced in newer Node.js versions.

The changes:

• Propagate the end argument through the internal Buffer search APIs.
• Update indexOfBuffer, indexOfNumber, indexOfNeedle, and findLastIndex to accept and forward the new parameter.
• Re-enable the corresponding Node compatibility test.

Testing

• ./x test-compat parallel/test-buffer-indexof.js

AI Disclosure

I used Cloude to help understand the Node.js implementation, discuss the design, and review the proposed changes + Write this description for me. The implementation, testing, and final code changes were completed and verified by me.

[Medo-ID]

Hi! When you have some time, could you please review this PR?

Notes:

• The changes in ext/node/polyfills/internal/buffer.mjs are copied directly from Node's implementation.
• The changes in ext/node/polyfills/internal_binding/buffer.ts are my implementation and would especially benefit from verification to ensure they match the intended behavior.
• My first attempt failed CI. In the second commit, I fixed the formatting/lint issues and corrected the loop condition from:

// buffer.ts - line 50
  for (let i = start; i < lastStart; i += step) {

to :

// buffer.ts - line 50
  for (let i = start; i <= lastStart; i += step) {

After those changes, the checks passed.

[bartlomieju]

Nice work, this tracks Node's lib/buffer.js wrappers and the C++ search semantics closely. I traced every assertion in the re-enabled test through the port and they all check out.

Two small divergences from Node's C++ (src/node_buffer.cc) that the test doesn't currently exercise, so they're latent rather than failing. Both are in indexOfBuffer in ext/node/polyfills/internal_binding/buffer.ts right around:

end = end < targetBufferLength ? end : targetBufferLength;

1. Missing max(end, 0) clamp. Node computes search_end = min(max(end, 0), haystack_length) (node_buffer.cc, the search_end line). We only do the min side. It only surfaces for the empty-needle + negative-end case: Buffer.from('abcabc').indexOf('', 0, -1) returns -1 here vs Node's 0 (Node clamps min(opt_offset, search_end) with search_end floored at 0). Obscure, but a real parity gap.

2. Missing UCS2 even-rounding. Node does if (enc == UCS2) search_end &= ~1 so the search range is a whole number of 16-bit units. We don't. In practice it's masked by the step = 2 alignment from an even byteOffset, so I couldn't build a failing case with even offsets, only a theoretical odd-offset ucs2 case the test never passes.

Both are cheap to close if we want byte-exact parity:

end = end < targetBufferLength ? end : targetBufferLength;
if (end < 0) end = 0;
if (isUcs2) end &= ~1;

Neither blocks the PR since the test passes as written; up to you whether to fold them in now or leave a follow-up.

[Medo-ID]

Thanks! I'll add unit tests to cover these additional cases that were missing from the upstream test-buffer-indexof.js:

• Empty needle with a negative end should clamp to 0, matching Node's search_end = min(max(end, 0), haystack_length).
• ucs2/utf16le searches should round an odd end down to the nearest code unit boundary (search_end &= ~1).

Notes

I'll also update the TypeScript declarations for indexOf, includes, and lastIndexOf in ext/node/polyfills/internal/buffer.d.ts to include the new end parameter.

While investigating the type errors, I also found that cli/tsc/dts/node/buffer.d.cts needs to be updated as well; otherwise calls such as buf.indexOf("", 0, -1) and buf.indexOf("", 0, 3, "ucs2") fail type checking.

One question: for the new overloads, should the signature be

byteOffset: number | undefined,
end: number,

or should both parameters remain optional?

byteOffset?: number,
end?: number,

I believe the first option is more appropriate because end is only meaningful when byteOffset is provided, but I'd appreciate your confirmation before finalizing the typings.