Somewhat surprised 262 didn't catch this. Am I being too naive or is this it?

Yours might be the better fix but I took a different approach in #989 because the ECMA spec language is woolly enough that I'm not sure if what you're doing here is legal.

And no, there are no test262 tests that cover this (or at least, I haven't been able to find them.)

Interesting!

If i'm reading this right, with your PR the byteLength won't be updated, right? V8 / JSC seem to update it, when checking with Node / Bun.

Yeah, and updating is sensible behavior, but common sense never stopped TC39 before, so 🤷

Note how your change breaks a number of DataView tests, although maybe that's simply because they expect RangeErrors instead of a TypeErrors, or vice versa.

What's your take? I don't have a strong opinion :-) If you think yours is the better fix I'm happy to close this.

If you can get the tests to pass, your way is probably better. Aligning with what other engines do would be good.

Alright, I'll give that a try!

I think I got it. The problem is we need to differentiate between the AUTO byte length and the non-auto case in order to adjust it: https://tc39.es/ecma262/multipage/structured-data.html#sec-dataview-constructor

We currently don't, and updating the length will be dependent on that.

I'll try to get it fixed tonight.

@bnoordhuis Updated, PTAL! I also incorporated your test.