WebAssembly is being designed to support C and C++ code well, right from the start in the MVP. The following explains the outlook for C and C++ developers.
WebAssembly has a pretty conventional ISA: 8-bit bytes, two's complement integers, little-endian, and a lot of other normal properties. Reasonably portable C/C++ code should port to WebAssembly without difficultly.
In the MVP, WebAssembly will have an ILP32 data model, meaning
that int, long, and pointer types are all 32-bit. The long long
type is 64-bit.
In the future, WebAssembly will be extended to support
64-bit address spaces. This
will enable an LP64 data model as well, meaning that long and pointer
types will be 64-bit, while int is 32-bit. From a C/C++ perspective,
this will be a separate mode from ILP32, with a separate ABI.
C and C++ language conformance is largely determined by individual compiler support, but WebAssembly includes all the functionality that popular C and C++ compilers need to support high-quality implementations.
While the MVP will be fully functional, additional features enabling greater performance will be added soon after, including:
-
Zero-cost C++ exception handling. C++ exceptions can be implemented without this, but this feature will enable them to have lower runtime overhead.
-
Support for 128-bit SIMD. SIMD will be exposed to C/C++ though explicit APIs such as LLVM's vector extensions and GCC's vector extensions, auto-vectorization, and emulated APIs from other platforms such as
<xmmintrin.h>.
WebAssembly applications can use high-level C/C++ APIs such as the C and C++ standard libraries, OpenGL, SDL, pthreads, and others, just as in normal C/C++ development. Under the covers, these libraries implement their functionality by using low-level facilities provided by WebAssembly implementations. On the Web, they utilize Web APIs (for example, OpenGL is executed on WebGL, libc date and time methods use the browser's Date functionality, etc.). In other contexts, other low-level mechanisms may be used.
In the MVP, WebAssembly does not yet have a stable ABI for libraries. Developers will need to ensure that all code linked into an application are compiled with the same compiler and options.
In the future, when WebAssembly is extended to support dynamic linking, stable ABIs are expected to be defined in accompaniment.
WebAssembly doesn't change the C or C++ languages. Things which cause undefined behavior in C or C++ are still bugs when compiling for WebAssembly [even when the corresponding behavior in WebAssembly itself is defined] (Nondeterminism.md#note-for-users-of-c-c-and-similar-languages). C and C++ optimizers still assume that undefined behavior won't occur, so such bugs can still lead to surprising behavior.
For example, while unaligned memory access is fully defined in WebAssembly, C and C++ compilers make no guarantee that a (non-packed) unaligned memory access at the source level is harmlessly translated into an unaligned memory access in WebAssembly. And in practice, popular C and C++ compilers do optimize on the assumption that alignment rules are followed, meaning that they don't always preserve program behavior otherwise.
On WebAssembly, the primary invariants are always maintained. Demons can't actually fly out your nose, as that would constitute an escape from the sandbox. And, callstacks can't become corrupted.
Other than that, programs which invoke undefined behavior at the source language level may be compiled into WebAssembly programs which do anything else, including corrupting the contents of the application heap, calling APIs with arbitrary parameters, hanging, trapping, or consuming arbitrary amounts of resources (within the limits).
Tools are being developed and ported to help developers find and fix such bugs in their code.
Most implementation-defined behavior in C and C++ is dependent on the compiler rather than on the underlying platform. For those details that are dependent on the platform, on WebAssembly they follow naturally from having 8-bit bytes, 32-bit and 64-bit two's complement integers, and [32-bit and 64-bit IEEE-754-style floating point support] (AstSemantics.md#floating-point-operations).
WebAssembly can be efficiently implemented on a wide variety of platforms, provided they can satisfy certain basic expectations.
WebAssembly has very limited nondeterminism, so it is expected that compiled WebAssembly programs will behave very consistently across different implementations, and across different versions of the same implementation.