[whatwg/encoding] "Peek" indexes the I/O queue from 1, skipping the first item (Issue #367)

atiernan created an issue (whatwg/encoding#367)

### What is the issue with the Encoding Standard?

The [peek](https://encoding.spec.whatwg.org/#i-o-queue-peek) algorithm says, in step 3:

> For each n in the range 1 to number, inclusive:
> 1. If ioQueue[n] is end-of-queue, break.
> 2. Otherwise, append ioQueue[n] to prefix.

Infra list indexing is [zero-based](https://infra.spec.whatwg.org/#list), so this collects `ioQueue[1]` through `ioQueue[number]`: it skips the first item and includes one item too many. Taken literally:

- [UTF-8 decode](https://encoding.spec.whatwg.org/#utf-8-decode) step 1 peeks at bytes 1–3, so a leading EF BB BF is not detected as a BOM.
- [BOM sniff](https://encoding.spec.whatwg.org/#bom-sniff) step 1 has the same problem.
- Step 1 waits only until the queue's size is at least `number`, or the queue contains end-of-queue. If the size is exactly `number` and there is no end-of-queue, `ioQueue[number]` is out of bounds. For an empty, finished queue (just end-of-queue), `ioQueue[1]` is out of bounds. Infra says the index cannot be out-of-bounds.

The intent is clearly the first `number` items, and that is what implementations and the BOM tests in WPT `encoding/` do.

Suggested fix: in step 3, replace "the range 1 to number, inclusive" with "[the range](https://infra.spec.whatwg.org/#the-exclusive-range) 0 to number, exclusive". That also covers `number` = 0, because Infra defines that range as empty when the bounds are equal.

The wording dates from #215.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/367
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/encoding/issues/367@github.com>