Re: [whatwg/encoding] Add support for [AllowResizable] inputs (Issue #344)

WebReflection left a comment (whatwg/encoding#344)

> Should the API attempt to grow the buffer if the input doesn't fit, for instance?

no, the returned `written` value is clear already and works as expected when the buffer is not *shared* so I think it should do exactly what it does with every single buffer so expectations are clear and less magic is involved, specially because the new length might not be available if it exceeds `maxByteLength` so I'd keep it simple, to be honest, as long as we can work with resizable buffers.

This is also because while a *SharedArrayBuffer* can only grow, *ArrayBuffer* can shrink so that if the new length is silently ignored there's no way to regain a one-off possible overly-demanding encoding (i.e. a very long string when the norm is a short one).

For *SaB* that's inevitable and a new *SaB* might be created, when needed, but those returned values help to properly orchestrate any logic around.

> can the write be atomic so it doesn't grow or shrink at the same time we are writing into it?

it needs to be atomic, hence it should not grow it while writing ... let developers deal with it and let them use properly the `read` and `written` returned values ... keep it consistent and don't change the logic, just accept resizable buffers or *SaB*?

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

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