[llvm-dev] getelementptr inbounds with offset 0

[Bruce Hoult via llvm-dev]

LLVM has no idea whether the address computed by GEP is actually
within a legal object. The "inbounds" keyword is just you, the
programmer, promising LLVM that you know it's ok and that you don't
care what happens if it is actually out of bounds.

https://llvm.org/docs/GetElementPtr.html#what-happens-if-an-array-index-is-out-of-bounds

On Sun, Feb 24, 2019 at 9:05 AM Ralf Jung via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> What exactly are the rules for `getelementptr inbounds` with offset 0?
>
> In Rust, we are relying on the fact that if we use, for example, `inttoptr` to
> turn `4` into a pointer, we can then do `getelementptr inbounds` with offset 0
> on that without LLVM deducing that there actually is any dereferencable memory
> at location 4.  The argument is that we can think of there being a zero-sized
> allocation. Is that a reasonable assumption?  Can something like this be
> documented in the LangRef?
>
> Relatedly, how does the situation change if the pointer is not created "out of
> thin air" from a fixed integer, but is actually a dangling pointer obtained
> previously from `malloc` (or `alloca` or whatever)?  Is getelementptr inbounds`
> with offset 0 on such a pointer a NOP, or does it result in `poison`?  And if
> that makes a difference, how does that square with the fact that, e.g., the
> integer `0x4000` could well be inside such an allocation, but doing
> `getelementptr inbounds` with offset 0 on that would fall under the first
> question above?
>
> Kind regards,
> Ralf
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev