[spec/function] Specify null dereference behavior for `@safe` code

[ntrel]

Forbid optimizations which assume a null dereference will not occur. ldc2 does use those optimizations with -O2 - see: https://forum.dlang.org/post/[email protected]. Fixes #4240.

Cc @tgehr @WalterBright.

Specify that the code generated must detect null dereferences if the system (by default) does not. Specify that the code generated must detect when any expression causes a null pointer to be indexed outside the protected first page. Include warning that dmd does not implement this yet - see https://github.com/dlang/dmd/issues/17776.

[dlang-bot]

Thanks for your pull request and interest in making D better, @ntrel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon. Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[ntrel]

Walter from https://forum.dlang.org/post/[email protected]:

D relies on the null dereference not being "optimized away". Maybe there's a switch for that on ldc, there should be if there isn't one.

That needs to be in the spec, hence this pull.

[rikkimax]

This is going to need @kinke and @ibuclaw also, as they support targets that the codegen doesn't currently offer read barriers that would require them.

[ibuclaw]

It's probably no big deal to "bounds check" pointer and class deferences in safe code only. Pointer slicing and indexing is already disallowed, and array slicing/indexing should rightly assume the underlying structure of the array isn't corrupted.

[ntrel]

Timon & Derek Fawcus on the forum found this for LLVM:

If "null-pointer-is-valid" is set to "true", then null address in address-space 0 is considered to be a valid address for memory loads and stores. Any analysis or optimization should not treat dereferencing a pointer to null as undefined behavior in this function

From under https://releases.llvm.org/10.0.0/docs/LangRef.html#function-attributes.

[kinke]

@ibuclaw: Do you explicitly opt out of these null-deref optimizations for GDC? Apparently not just for @safe functions. I'm wondering if I should really only restrict it to @safe functions.

[ibuclaw]

@ibuclaw: Do you explicitly opt out of these null-deref optimizations for GDC? Apparently not just for @safe functions. I'm wondering if I should really only restrict it to @safe functions.

I don't think GCC implements null dereference optimizations.

Off the top of my head, infinite loop optimizations are opt-in. As it's part of C++ language to assume all loops are finite.

That is to say, if any nul pointer opts do exist its probably opt-in as well.

[kinke]

Oh I see, it's only clang that 'optimizes' the artificial tiny testcase, not gcc.