Apparent contradiction between nomicon and reference docs for ZST pointers

[Lucretiel]

There's a passage of the nomicon that reads:

So if the allocator API doesn't support zero-sized allocations, what on earth do we store as our allocation? Unique::empty() of course! Almost every operation with a ZST is a no-op since ZSTs have exactly one value, and therefore no state needs to be considered to store or load them. This actually extends to ptr::read and ptr::write: they won't actually look at the pointer at all. As such we never need to change the pointer.

However, the docs for ptr::read state:

Note that even if T has size 0, the pointer must be non-NULL and properly aligned.

Is this a contradiction? The former passage states that ptr::read for a ZST is a "no-op" that "won't actually look at the pointer at all", which would seem to imply it doesn't matter what data you pass to it, but the latter passage states that it DOES matter, you must pass an aligned, non-null pointer.

[SNCPlay42]

As far as I know it's likely correct that ptr::read/write on ZSTs do nothing when they're well defined, so the nomicon isn't entirely incorrect to call them "no-ops". But that doesn't mean they aren't undefined for null or unaligned pointers. So there sort of is and isn't a contradiction, depending on how you read it - by "they won't actually look at the pointer", does the nomicon mean "they won't look at the pointed memory", or "they won't look at the actual pointer"? It should definitely avoid implying the latter, so the wording should be changed.

It's worth noting that Unique::empty() (and its stable equivalent NonNull::dangling()) is a non-null, properly aligned pointer, so the actual code in the nomicon shouldn't be broken.

[nico-abram]

Should the it also reference NonNull::dangling instead of Unique::empty?