setFromBase64 Test262 failure: fix in V8 or simdutf?

[Temiloluwa]

Hi V8 devs,

I looked into the skipped Test262 test built-ins/Uint8Array/prototype/setFromBase64/trailing-garbage, and I confirmed that it still fails on current V8.

The issue occurs when valid Base64 input completely fills the output array. For example:

new Uint8Array(3).setFromBase64("aaaa#");

The first four characters decode to three bytes, which fills the array. According to the ECMA-262 FromBase64 algorithm, decoding should stop at that point and return:

{ read: 4, written: 3 }

V8 writes the three expected bytes, but simdutf continues to the #, reports an error, and V8 throws a SyntaxError.

I also reproduced this with the current upstream simdutf code, so updating the simdutf dependency alone would not fix it.

I considered handling this in V8 by ignoring the error when the output array is full, but that could return the wrong readvalue. For example:

• With "a a a a #", the expected read value is 7, but simdutf reports 8.
• With "aaaaa", the expected read value is 4, but simdutf reports 5.

would you recommend fixing this behaviour in simdutf first and then updating v8 to use that fix or handling it in v8 around the simdutf call?

[Jakob Kummerow]

While I haven't looked into this particular issue, as a general rule upstream fixes are preferable whenever they are feasible. If upstream is not interested for some reason or not responsive, then a workaround on the V8 side is a reasonable plan B.

Thanks for asking, and for your efforts!

--