the semantics of pointer validation apis are a bit vague wrt NULL

[yamt]

we provide a few variations of pointer validation functions for embedders. eg. wasm_runtime_validate_native_addr

however, it's a bit unclear if NULL is considered "valid" or not for these functions.

looking at the implementation of wasm_runtime_validate_native_addr, it checks the given pointer like the following:

    uint8 *addr = (uint8 *)native_ptr;

if (memory_inst->memory_data <= addr

iirc, "<" operatior on a null pointer is an undefined behavior in C. i suppose for many of relevant architectures it works as if it was a "zero" address. and i guess it's what this logic is intended. ie. NULL is NOT a valid pointer.

otoh, wasm_runtime_validate_app_addr seems to consider NULL is valid. it's understandable because 0 is a valid linear memory address in wasm. it's however confusing as we sometimes converts wasm NULL to native NULL. (and vice versa.)

anyway, i'd suggest to do:

• explicitly mention the semantics in the api documentation.
• avoid relying on an undefined behavior in the implementation.

[TianlongLiang]

so for the implementation, the modification will be like adding a test whether the native pointer is NULL, if it's NULL, return false. right?

[yamt]

my suggestions:

• stop converting wasm NULL to native NULL. (and vice versa) an example of the code to be fixed
• make wasm_runtime_validate_app_addr etc return false for native NULL. (w/o relying on UD) or, maybe it's simpler to use bh_assert(addr != NULL).
• for native functions which want to give a special meaning to wasm NULL, make them check the wasm address by themselves. in the core part of the runtime, just treat wasm addr 0 as an ordinary address.