On Linux, command line arguments cannot contain multi-byte codepoints because of limitation on the String type about bflat HOT 5 OPEN

You're running into the FailFast, right? Yeah, zerolib does cut corners like that. This constructor has different behaviors depending on whether this is Windows or Linux (it's "current codepage to UTF-16" on Windows, and "UTF-8 to UTF-16" on Linux).

from bflat.

Well, it's not 'UTF-8 to UTF-16' on Linux, it is 'ASCII to UTF-16' (by design). It seems too limiting, even for zerolib. But perhaps you feel differently?

from bflat.

I'm not opposed to adding a helper for this. It might not be the only place where utf-8 to 16 would be useful.

from bflat.

I am keeping track of everything that 'feels like' zerolib in a single file. Perhaps worth doing a simple PR, or discussion, when I am finished.

In case you wonder ... I am playing around with exposing utf8 cmd line args in the spirit of utf8everywhere, moving on experimenting with a no-allocation programming model (as MISRA C), to finish with a linear allocator. At least, this is the rough idea, we'll see.

from bflat.

On Windows, I think using the Windows API. On Linux, I think using libiconv. Don't write your own encoding converter.

from bflat.