From de455af1cd7e94e5940262f1511b1be5fc8dc1a3 Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Tue, 2 Jun 2015 02:08:59 -0700 Subject: Tighten up the language about observable differences between implementations. --- IncompletelySpecifiedBehavior.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'IncompletelySpecifiedBehavior.md') diff --git a/IncompletelySpecifiedBehavior.md b/IncompletelySpecifiedBehavior.md index f566aba..2bdf9d2 100644 --- a/IncompletelySpecifiedBehavior.md +++ b/IncompletelySpecifiedBehavior.md @@ -2,9 +2,9 @@ WebAssembly is a sandboxed platform. Applications can't access data outside the sandbox without going through appropriate APIs, or otherwise escape the sandbox, even if the behavior inside the sandbox should ever be unspecified in any way. -Beyond that, it is desirable to minimize observable differences between implementations when practical, so that applications don't inadvertently become dependent on any particular implementation's behavior. However, in some areas, performance concerns make this prohibitively expensive, so some compromises are made. +Beyond that, WebAssembly minimizes observable differences between implementations, to reduce the risk of applications becoming dependent on any particular implementation's behavior. However, occasionally compromises are made due to performance concerns, listed below. -Also, there is a general preference against [nasal demons](https://en.wikipedia.org/w/index.php?title=Nasal_demons), since they are an extreme on the spectrum of observable differences, and since they make it difficult to reason about what state an application might be in. WebAssembly usually prefers to [trap](AstSemantics.md). Otherwise, it is generally preferred to have a specific set of possible behaviors rather than nasal demons. And presently, WebAssembly has no nasal demons. +In particular, WebAssembly has no [nasal demons](https://en.wikipedia.org/w/index.php?title=Nasal_demons), since they are an extreme on the spectrum of observable differences, and since they make it difficult to reason about what state an application might be in. WebAssembly prefers to [trap](AstSemantics.md) when feasible, and otherwise it permits a specific set of possible conforming behaviors. The following is a list of the places where the WebAssembly specification currently admits or is expected to admit multiple possible behaviors. -- cgit v1.2.3 From eac29775795b034a65724b1de71d2db31f91a1cd Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Tue, 2 Jun 2015 02:09:41 -0700 Subject: Add a paragraph describing about control flow properties. --- IncompletelySpecifiedBehavior.md | 2 ++ 1 file changed, 2 insertions(+) (limited to 'IncompletelySpecifiedBehavior.md') diff --git a/IncompletelySpecifiedBehavior.md b/IncompletelySpecifiedBehavior.md index 2bdf9d2..4d82de3 100644 --- a/IncompletelySpecifiedBehavior.md +++ b/IncompletelySpecifiedBehavior.md @@ -2,6 +2,8 @@ WebAssembly is a sandboxed platform. Applications can't access data outside the sandbox without going through appropriate APIs, or otherwise escape the sandbox, even if the behavior inside the sandbox should ever be unspecified in any way. +WebAssembly always maintains valid callstacks. Return addresses are stored on the trusted stack and can't be clobbered by the application. And, WebAssembly ensures that calls and branches always have valid destinations. + Beyond that, WebAssembly minimizes observable differences between implementations, to reduce the risk of applications becoming dependent on any particular implementation's behavior. However, occasionally compromises are made due to performance concerns, listed below. In particular, WebAssembly has no [nasal demons](https://en.wikipedia.org/w/index.php?title=Nasal_demons), since they are an extreme on the spectrum of observable differences, and since they make it difficult to reason about what state an application might be in. WebAssembly prefers to [trap](AstSemantics.md) when feasible, and otherwise it permits a specific set of possible conforming behaviors. -- cgit v1.2.3 From 766d32362828ba263977faca493ef82a132b709e Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Tue, 2 Jun 2015 02:10:26 -0700 Subject: Add a section discussing C and C++. --- IncompletelySpecifiedBehavior.md | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'IncompletelySpecifiedBehavior.md') diff --git a/IncompletelySpecifiedBehavior.md b/IncompletelySpecifiedBehavior.md index 4d82de3..96b4037 100644 --- a/IncompletelySpecifiedBehavior.md +++ b/IncompletelySpecifiedBehavior.md @@ -21,3 +21,13 @@ The following is a list of the places where the WebAssembly specification curren - [Fixed-width SIMD may want some flexibility](EssentialPostMVPFeatures.md#fixed-width-simd) - In SIMD.js, floating-point values may or may not have subnormals flushed to zero. - In SIMD.js, operations ending in "Approximation" return approximations that may vary between platforms. + +## Note for users of C, C++, and similar languages + +Some operations which have fully defined behavior in WebAssembly itself may nonetheless have undefined behavior at the source code level. 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](Tooling.md) to help developers find and fix bugs in their code. -- cgit v1.2.3 From e5cc7b9a30a81e18ca8706daa09ca6912af027b9 Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Tue, 2 Jun 2015 07:11:09 -0700 Subject: Say "floating point" instead of "floating-point". --- IncompletelySpecifiedBehavior.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'IncompletelySpecifiedBehavior.md') diff --git a/IncompletelySpecifiedBehavior.md b/IncompletelySpecifiedBehavior.md index 96b4037..b3679d0 100644 --- a/IncompletelySpecifiedBehavior.md +++ b/IncompletelySpecifiedBehavior.md @@ -19,7 +19,7 @@ The following is a list of the places where the WebAssembly specification curren - [Races between threads](EssentialPostMVPFeatures.md#threads) - [Fixed-width SIMD may want some flexibility](EssentialPostMVPFeatures.md#fixed-width-simd) - - In SIMD.js, floating-point values may or may not have subnormals flushed to zero. + - In SIMD.js, floating point values may or may not have subnormals flushed to zero. - In SIMD.js, operations ending in "Approximation" return approximations that may vary between platforms. ## Note for users of C, C++, and similar languages -- cgit v1.2.3