[llvm-dev] [RFC] Introducing a byte type to LLVM

[Nicolai Hähnle via llvm-dev]

On Mon, Jun 21, 2021 at 9:08 PM John McCall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 21 Jun 2021, at 2:15, Juneyoung Lee wrote:
>
> actually have semantics for pointer castings tailored to LLVM (link
> <https://sf.snu.ac.kr/publications/llvmtwin.pdf>).
> In this proposal, ptrtoint does not have an escaping side effect; ptrtoint
> and inttoptr are scalar operations.
> inttoptr simply returns a pointer which can access any object.
>
> Skimming your paper, I can see how this works *except* that I don’t
> see any way not to treat ptrtoint as an escape. And really I think
> you’re already partially acknowledging that, because that’s the only
> real sense of saying that inttoptr(ptrtoint p) can’t be reduced to
> p. If those are really just scalar operations that don’t expose
> p in ways that might be disconnected from the uses of the inttoptr
> then that reduction ought to be safe.
>

I haven't read the paper yet, but I think the argument is: Assume p was
obtained via an out-of-bounds GEP that happens to point at valid memory
that belongs to a different object than p's provenance. In that case,
dereferencing inttoptr(ptrtoint(p)) is defined behavior ("inttoptr simply
returns a pointer which can access any object") while dereferencing p is UB.

Cheers,
Nicolai



> John.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210622/e05188d8/attachment.html>