Well, that's kind of what the README file is there for.
Here is my understanding: The C program assumes the C standard library is present. It is present, somewhere. Where, and in what version, is not clear to me.
Anyway, while the C standard library has an implementation of printf(), that implementation doesn't actually know how to do I/O. It relies on an underlying operating system to do the actual I/O. In particular, the library assumes that it is running on Linux, so once in a while it will emit system call number 146, which is Linux's writev(2) system call (http://man7.org/linux/man-pages/man2/writev.2.html). But there is no implementation of Linux running in the browser! And if there were, its conception of I/O would probably be different from what you expect. That is, you might want "output" to go to one of many different places, and WebAssembly can't guess what you want. That's why the program also implements a writev_c function to simulate this syscall. The corresponding mapping from syscall number 146 to this function is implemented in the accompanying main.js file.
So to program your browser in C-compiled-to-WebAssembly, you must implement your high-level application logic and the relevant low-level system calls, making educated guesses (through testing) about what syscalls the hidden mid-level library layer will emit. I'm a bit underwhelmed by this approach. But I guess over time standard syscall libraries will pop up and included in WebAssembly projects to allow you to go back to worrying only about your actual application.
That’s a very nice description of what’s going on. The example is there to illustrate how printf works. In fact this is a lot of what Emscripten does to make C/C++ applications just work.
Here is my understanding: The C program assumes the C standard library is present. It is present, somewhere. Where, and in what version, is not clear to me.
Anyway, while the C standard library has an implementation of printf(), that implementation doesn't actually know how to do I/O. It relies on an underlying operating system to do the actual I/O. In particular, the library assumes that it is running on Linux, so once in a while it will emit system call number 146, which is Linux's writev(2) system call (http://man7.org/linux/man-pages/man2/writev.2.html). But there is no implementation of Linux running in the browser! And if there were, its conception of I/O would probably be different from what you expect. That is, you might want "output" to go to one of many different places, and WebAssembly can't guess what you want. That's why the program also implements a writev_c function to simulate this syscall. The corresponding mapping from syscall number 146 to this function is implemented in the accompanying main.js file.
So to program your browser in C-compiled-to-WebAssembly, you must implement your high-level application logic and the relevant low-level system calls, making educated guesses (through testing) about what syscalls the hidden mid-level library layer will emit. I'm a bit underwhelmed by this approach. But I guess over time standard syscall libraries will pop up and included in WebAssembly projects to allow you to go back to worrying only about your actual application.