Reader.peekDelimiterInclusive: Fix handling of stream implementations that return 0

[squeek502]

Previously, the logic in peekDelimiterInclusive (when the delimiter was not found in the existing buffer) used the n returned from r.vtable.stream as the length of the slice to check, but it's valid for vtable.stream implementations to return 0 if they wrote to the buffer instead of w. In that scenario, the indexOfScalarPos would be given a 0-length slice so it would never be able to find the delimiter.

This commit changes the logic to assume that r.vtable.stream can both:

• return 0, and
• modify seek/end (i.e. it's also valid for a vtable.stream implementation to rebase)

Also introduces std.testing.ReaderIndirect which helps in being able to test against Reader implementations that return 0 from stream/readVec

Fixes #25428

---

Before this PR, the added "takeDelimiterInclusive on an indirect reader when it rebases" test would fail with error.StreamTooLong since it'd always be searching for the delimiter in a 0-length slice.

---

This is a very targeted fix. It does not address any of the following:

• std.Io.takeDelimiter tosses too many characters #25132
• std.Io.Reader.takeDelimiterExclusive() return error.StreamTooLong instead of error.EndOfStream #24950
• 8023f3d

It also assumes that the stream ambiguity described in #25170 should be resolved in the "writing to w cannot modify the buffer" way (i.e. this fix assumes that no implementation will try to write to both buffer and w in the same stream call).

(see also #25169 for some extra context around those issues)

---

The added "readSliceShort with indirect reader" test is just to verify the std.testing.ReaderIndirect implementation around rebasing within stream (without the rebase within stream, that test would enter an infinite loop).

[kaizoplant]

ive been trying out this implementation, and i was wondering about this line

if (std.mem.indexOfScalarPos(u8, r.buffer[r.seek..r.end], existing_buffered_len, delimiter)) |delimiter_index| {
     return r.buffer[r.seek .. delimiter_index + 1];
}

i think if im not incorrect, what should be returned is

r.buffer[r.seek .. r.seek + delimiter_index + 1]

since if seek is non-zero, then the delimiter will be at the wrong spot
alternatively, i think the following also works

if (std.mem.indexOfScalarPos(u8, r.buffer[0..r.end], r.seek + existing_buffered_len, delimiter)) |delimiter_index| {
    return r.buffer[r.seek .. delimiter_index + 1];
}

idk if any of those would be particularly better or worse but yeah

[squeek502]

Good catch. Will try to alter the test so that it fails with my broken version.

EDIT: Actually, it's not really feasible to construct a failing test, or at least without using a vtable.stream implementation that advances the seek position (which seems like it should violate the API, see #25170 for more on that)

Note also that involving r.seek here instead of assuming it is 0 is mostly an attempt at future-proofing depending on how #25103 is resolved.

[daurnimator]

@squeek502 I'm wondering if this PR is potentially the cause of https://gitlab.archlinux.org/archlinux/packaging/packages/ncdu/-/issues/3#note_342986 ?

Relevant code I guess? https://code.blicky.net/yorhel/ncdu/src/commit/14bb8d0dd186d7bfe493674455baf22f4f65f16b/src/util.zig#L226-L239

I also created https://code.blicky.net/yorhel/ncdu/issues/266

[squeek502]

@daurnimator I think you might be running into #25597 (comment)

(side note: the changes in this PR were obsoleted by #25512 where peekDelimiterInclusive was reworked)