TwoByte is not ideal agreed, I like USC but does that imply some guarantees for missing surrogate pairs?
That's mainly the issue we have with the current utf8 conversion.
The best test case would be "🌍🌎🌎".slice(1), we should have a way to retrieve the bytes 0d df 3c d8 0e df 3c d8 0f df
If I remember you guys do "lazy" utf16 too right?

The failing test was this (on meson on ubuntu-latest (default debug, mimalloc)):

 /home/runner/work/quickjs/quickjs/build-debug/../tests/test_std.js:253: Error: assertion failed: got |0|, expected |15|

That's the assert(status & 0x7f, os.SIGTERM) that's also flaky under cygwin.

I like USC but does that imply some guarantees for missing surrogate pairs?

Nothing that JS strings don't already promise (i.e., not much.)

Why not simply JS_ToCStringUTF16, more explicit and self explanatory ?

Or possibly JS_ToWCString with obvious and less obvious connotations...

Why not simply JS_ToCStringUTF16, more explicit and self explanatory ?

Unmatched surrogate pairs. JS strings that have them are not legal UTF-16. That was the reason for the TwoByte moniker, to convey to users they can't assume well-formed UTF-16.

Or possibly JS_ToWCString with obvious and less obvious connotations...

To seasoned C programmers that name suggests it's using wchar_t when it isn't. There's probably a special circle in Hell for programmers who commit such crimes against humanity. I don't know about you but I'd like to go to Heaven.

Half tongue in cheek (half, because I do like to go to Heaven); wdyt, @saghul?

🤣

I think UTF16 with docs or UCS as the part in the name works for me.

Okay, here's the plan: I'm going to merge this PR and then open a new one that s/TwoByte/UTF16/g