Open sgbeal opened 2 years ago
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.
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.)
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.
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?