Stream: t-lang/wg-unsafe-code-guidelines

Topic: what's an access?


gnzlbg (Feb 24 2019 at 08:59, on Zulip):

Is:

let x: *mut ();
let y: () = *x; // Is this an access?

What about:

let (x, y): (*mut i32, *mut i32);
ptr::copy(x, y, 0); // Is this an access?
gnzlbg (Feb 24 2019 at 09:01, on Zulip):

I thought that reading or writing some memory are accesses, but reading / writing no memory are not accesses. But that would make dereferencing a pointer to a ZST not an access.

This is why I don't understand the discussion about whether accesses to ZSTs are valid. I thought these weren't accesses at all.

If dereferencing a pointer to a ZST accesses something, what does it access? It does not access any memory or place.

RalfJ (Feb 24 2019 at 11:30, on Zulip):

let y: () = *x; // Is this an access?

this is a zero-sized access. the details for that are still somewhat unclear, see https://github.com/rust-rfcs/unsafe-code-guidelines/issues/93

RalfJ (Feb 24 2019 at 11:33, on Zulip):
let (x, y): (*mut i32, *mut i32);
ptr::copy(x, y, 0); // Is this an access?

no, this is not. but the pointer must still be aligned and non-NULL.

RalfJ (Feb 24 2019 at 11:36, on Zulip):

but yes, we could also rule that zero-sized "accesses" nor not accesses. and that's in fact what Miri implements. (Note that the ptr does need to be aligned though, the alignment check happens before actually doing an access.)

RalfJ (Feb 24 2019 at 11:37, on Zulip):

but that still leaves the problem with zero-offset GEP. If zero-offset GEP is always valid, then I am fine also making zero-sized accesses "not really accesses". but imposing requirements on a zero-offset GEP and NOT on a zero-sized access, that is inconsistent IMO.

gnzlbg (Feb 24 2019 at 13:20, on Zulip):

Hm, just to check I follow. Iff a dereference of a pointer to a ZST is an access, but ptr::copy(x, y, 0) is not, then that is because ptr::copy checks the length first (0), and dereferences no pointers, therefore it performs no accesses ?

RalfJ (Feb 24 2019 at 15:28, on Zulip):

hm, yeah that's how I was imagining it. but I do agree that it is also somewhat inconsistent.

RalfJ (Feb 24 2019 at 15:28, on Zulip):

the best solution to me seems to be to allow getelementptr-by-0 on all pointers, but I am not sure if LLVM is happy with that.

gnzlbg (Feb 25 2019 at 08:32, on Zulip):

I think I can follow the reasoning: pointer dereferences are the primitive operation here, not copy.
I somehow expected it to be the other way around: pointer dereferences are not the primitive operation, memory copying is. A pointer dereference just copies memory from some address somewhere else.

Last update: Nov 19 2019 at 19:00UTC