Misinformation in the FS.init() docs

[sgbeal]

The FS.init() docs at:

https://emscripten.org/docs/api_reference/Filesystem-API.html#FS.init

say that the input proxy function "should return an ASCII character code..." and that the output proxies "will be called with an ASCII character code whenever the program writes..."

That cannot possibly be correct: ASCII is limited to the range 0-127, inclusive, and emscripten-compiled binaries have no problems outputting non-ASCII UTF-8 characters (e.g. emoji), all of which have bit 8 set (and are thus greater than 127).

Presumably the intent of those docs is that the functions must return an integer in the range 0..255, inclusive?

[sbc100]

Yes, you are correct, those callback can return arbitrary bytes (integers in the range 0..255).

However, I do wonder if anyone is actually using those paramaters. All of our examples set Module['stderr'] etc instead. I wonder if we can remove that codepath.

[sgbeal]

FWIW, i assumed, without checking, that Module.print/printErr where set up via FS.init(). i have a pending C-to-wasm port which could hypothetically make use of FS.init(), as it streams minified CSS out a byte at a time (potentially splitting up multi-byte characters), but perhaps the same effect can be had with Module.print/printErr. (At this point the whole JS-to-C-via-wasm thing is too new to me to say for sure.)

[sbc100]

I think Module.print/printErr are separate. Module.print/printErr receive anything that gets sent to out or err functions. stdout and stderr default to going via the TTY object defined in library_tty.js which then writes using out and err which then redirect to print/printErr.

Setting stderr/stdout/stdin at the FS layer overrides this it seems.