10 ms·

It seems reasonable to me based on how memory is used in WebAssembly, and the constraints it runs under. The address space of a WASM module is limited to just t

It seems reasonable to me based on how memory is used in WebAssembly, and the constraints it runs under. The address space of a WASM module is limited to just that module. A null pointer in one module will never be the same as one in another module, so it's already unlike native code. Mandating that address 0 cannot be used places more constraints on what the browser engine can do when it compiles the module, and for some languages compiled to WASM this feature may not even be necessary. EDIT: As for your own edit, since you cannot do arithmetic on a pointer in Java, this does make it easier. NULL could be set to -1, which unless that module is using 4 gigabytes of memory will cause an out-of-bounds exception.

kllrnohj 4y ago
> Mandating that address 0 cannot be used places more constraints on what the browser engine can do when it compiles the module, and for some languages compiled to WASM this feature may not even be necessary. How do you figure? Just say the WASM heap starts at 0x1000 instead of 0x0 or whatever. Bam, done & done. The browser engine is already incorporating offsets to all the memory accesses anyway, the "real" addresses do not start at 0x0 of course. Edit: > EDIT: As for your own edit, since you cannot do arithmetic on a pointer in Java, this does make it easier. NULL could be set to -1, Well, you'd use something a bit farther away so that the internal engine also doesn't need to worry about small offsets from null (you're not always dereference 0x0 itself, but rather a field "nearby" after all) And yes Java can do that. So can C, for that matter, by defining NULL to be something else. But if everyone has to just reimplement guard pages in the upper 4GB address range, it gets back to why the hell didn't WASM just standardize that like every other MMU-based system? Why did WASM be an unfriendly snowflake? And of course once an mmap-like happens you lose your guard page safety. The runtime could still use the address range you hoped was invalid for something valid. You really need the runtime to guarantee the dead zone. Which a simple heap offset would have trivially achieved.
- shadowofneptune 4y ago
  That actually is not a bad solution. Keeps everything in alignment. I assumed your solution would keep addresses 1, 2, 3, etc... as valid.
- flohofwoe 4y ago
  > by defining NULL to be something else I bet that around 99% of C code in the real world assumes that NULL == 0. I'm sure that if it would be easy to make nullptr accesses trap in WASM browser runtimes without killing performance, the Emscripten team would have come up with a solution.
  - josefx 4y ago
    > I bet that around 99% of C code in the real world assumes that NULL == 0. That is the correct assumption as 0 is interpreted as a null pointer constant when interpreted as a pointer. As far as I understand you have to do something like memset(ptr,0,sizeof(int*)) to bypass this conversion and get a pointer to the memory location 0 instead of a NULL pointer.
    - saurik 4y ago
      Yeah, but that memset is super common due to how people clear structs.

kllrnohj 4y ago

> Mandating that address 0 cannot be used places more constraints on what the browser engine can do when it compiles the module, and for some languages compiled to WASM this feature may not even be necessary. How do you figure? Just say the WASM heap starts at 0x1000 instead of 0x0 or whatever. Bam, done & done. The browser engine is already incorporating offsets to all the memory accesses anyway, the "real" addresses do not start at 0x0 of course. Edit: > EDIT: As for your own edit, since you cannot do arithmetic on a pointer in Java, this does make it easier. NULL could be set to -1, Well, you'd use something a bit farther away so that the internal engine also doesn't need to worry about small offsets from null (you're not always dereference 0x0 itself, but rather a field "nearby" after all) And yes Java can do that. So can C, for that matter, by defining NULL to be something else. But if everyone has to just reimplement guard pages in the upper 4GB address range, it gets back to why the hell didn't WASM just standardize that like every other MMU-based system? Why did WASM be an unfriendly snowflake? And of course once an mmap-like happens you lose your guard page safety. The runtime could still use the address range you hoped was invalid for something valid. You really need the runtime to guarantee the dead zone. Which a simple heap offset would have trivially achieved.

shadowofneptune 4y ago
That actually is not a bad solution. Keeps everything in alignment. I assumed your solution would keep addresses 1, 2, 3, etc... as valid.
flohofwoe 4y ago
> by defining NULL to be something else I bet that around 99% of C code in the real world assumes that NULL == 0. I'm sure that if it would be easy to make nullptr accesses trap in WASM browser runtimes without killing performance, the Emscripten team would have come up with a solution.
- josefx 4y ago
  > I bet that around 99% of C code in the real world assumes that NULL == 0. That is the correct assumption as 0 is interpreted as a null pointer constant when interpreted as a pointer. As far as I understand you have to do something like memset(ptr,0,sizeof(int*)) to bypass this conversion and get a pointer to the memory location 0 instead of a NULL pointer.
  - saurik 4y ago
    Yeah, but that memset is super common due to how people clear structs.