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

Topic: memcpy out-of-bounds


gnzlbg (Nov 27 2018 at 09:02, on Zulip):

There was an issue somewhere about potential implementations of memcpy using vector instructions wanting to load memory out of bounds but I cannot find it. @briansmith ?

gnzlbg (Nov 27 2018 at 09:07, on Zulip):

@RalfJ see https://github.com/rust-lang/rust/issues/32976#issuecomment-441979177

gnzlbg (Nov 27 2018 at 09:07, on Zulip):

That's a second example about wanting to be able to read and modify memory that's out-of-bounds.

RalfJ (Nov 27 2018 at 10:16, on Zulip):

@gnzlbg do you mean https://github.com/rust-rfcs/unsafe-code-guidelines/issues/2 ?

gnzlbg (Nov 27 2018 at 10:16, on Zulip):

yeah

RalfJ (Nov 27 2018 at 10:16, on Zulip):

yeah all of that is currently UB until someone gets the LLVM devs to allow it, I think

RalfJ (Nov 27 2018 at 10:17, on Zulip):

these inbounds assumptions are used pervasively in alias analysis, I would not want to risk violating them

gnzlbg (Nov 27 2018 at 10:19, on Zulip):

Check out the Atomic integer issue.

gnzlbg (Nov 27 2018 at 10:19, on Zulip):

Basically, it is being argued that smaller atomic integer types can be emulated on top of larger ones.

gnzlbg (Nov 27 2018 at 10:20, on Zulip):

But that requires applying atomic memory operations for a larger type, which access memory out-of-bounds.

gnzlbg (Nov 27 2018 at 10:20, on Zulip):

So maybe the answer here is that no, smaller atomic integer types cannot be emulated on top of larger ones.

RalfJ (Nov 27 2018 at 10:30, on Zulip):

that is, I think, indeed the answer, at least with LLVM as the backend

gnzlbg (Nov 27 2018 at 11:52, on Zulip):

@RalfJ even with a different backend, to support this we would have to introduce memory operations that can read / write memory out-of-bounds (whether the reads / writes are atomic, volatile, or something else is irrelevant).

RalfJ (Nov 27 2018 at 11:56, on Zulip):

sure

nagisa (Nov 30 2018 at 16:46, on Zulip):

While at machine level emulating the atomics via CAS loop on a larger memory region is (just fine)™, it has to be done after LLVM (optimisation pipeline) gets it teeth to the code.

nagisa (Nov 30 2018 at 16:46, on Zulip):

i.e. implementing this in assembly is fine and so is fine to do so in instruction selection legalisation, I think.

RalfJ (Nov 30 2018 at 20:13, on Zulip):

yeah, maybe you can even do that in LLVM's later lower-level IRs

Last update: Nov 20 2019 at 13:05UTC