Fix Issue 20426 - doesPointTo with void[N] fails

[MoonlightSentinel]

Accept a false positive/negative for may/doesPointTo

[dlang-bot]

Thanks for your pull request and interest in making D better, @MoonlightSentinel! 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

Auto-close	Bugzilla	Severity	Description
✓	20426	normal	doesPointTo with void[N] fails

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#7458"

[n8sh]

If source is or contains a union, then there may be either false positives or false negatives

This PR should update the documentation to specify that false positives / false negatives are also possible if source is or contains a static array whose element type is void.

[n8sh]

We can do more than this in mayPointTo. Minimally return S.sizeof >= typeof(void*).sizeof as we know that a data chunk smaller than a pointer cannot contain a pointer. Maximally we could interpret every properly-aligned pointer-sized chunk of the static array as if it were a pointer, which is safe since we never actually dereference the pointer but merely compare it to other pointers.

[MoonlightSentinel]

Implemented the latter

[n8sh]

Branch for CTFE?

[MoonlightSentinel]

Added a __ctfe branch which pessimistically returns true because I didn't find a way to implement the actual logic without using a reinterpreting cast.

[n8sh]

I'm not sure if misaligned writes are guaranteed to work with LDC. I guess if some supported platform actually ignores the lowest few bits of a destination address that it "knows" is aligned on a word boundary, the automated test suite will tell us.

[MoonlightSentinel]

Would writing individual bytes using slice assignment work for all platforms? E.g.:

void*[1] tmp = [&b];
(cast(ubyte[]) voidArr[3 .. 3 + (void*).sizeof])[] = cast(ubyte[]) tmp[];

[n8sh]

Definitely.

[schveiguy]

I tried to make this work, you should be able to cast to some form of ubyte[], but the compiler refuses to see anything but a void[N]. I tried slicing, slicing a pointer, and using a helper function.

[n8sh]

Unfortunately there's a problem with the mayPointTo(void[n], T) check that didn't occur to me in time. Aside from containing pointers, the mystery memory region could also contain the language's built-in array slices that are represented as (length, pointer) pairs. Since we also don't know the element size, any (length, pointer) pair where the pointer is non-null and the length is non-zero potentially refers to the entire memory range from the pointer to the pointer plus the greatest multiple of the length that can be added to it without overflow.

IDK if it's worth checking this. It might be better to change mayPointTo(void[n], T) back to always returning true like in the first version of this PR.

[schveiguy]

Hm... I think it's worth revising, the use case that prompted this is TaggedAlgebraic, which uses a void[N] for storage. That could easily contain an array. Given that mayPointTo returning false is supposed to be "100% sure", I'd say we should opt for the cautious version.

[schveiguy]

We could still implement checks like if the N is 3, it can't be a pointer, or if it's 5, it can't be an array (on 32-bit), but I'd say that the easiest thing is to return true. It can be enhanced later if a need arises.