[LLVMdev] proposed new rule for getelementptr

[Török Edwin]

On 2009-07-22 21:30, Dan Gohman wrote:
> Hello,
>
> I'm working on refining the definition of getelementptr (GEP) to
> clarify its semantics and to allow front-ends to provide additional
> information to optimization passes.
>
> To help support this, I'd like to propose the following rule:
>
> Any memory access must be done though a pointer value associated
> with with address range of the memory access, otherwise the behavior
> is undefined.
>
> "associated with" is defined as follows:
>
>   - A pointer value formed from a getelementptr instruction is
>     associated with the addresses associated with the first operand of
>     the getelementptr.
>   - An addresses of a global variable is associated with the address
>     range of the variable's storage.
>   - The result value of an allocation instruction is associated with
>     the address range of the allocated storage.
>   - A null pointer is associated with no addresses.
>   - A pointer value formed by a ptrtoint is associated with all address
>     ranges of all pointer values that contribute (directly or
>     indirectly) to the computation of the pointer's value.
>   - An integer value other than zero may be associated with address
>     ranges allocated through mechanisms other than those provided by
>     LLVM; such ranges shall not overlap with any ranges of address
>     allocated by mechanisms provided by LLVM.
>   


What happens when you allocate more room for a variable than its type
says it needs,
and then access the variable beyond the limit of what its type would
allow (but is otherwise valid, because you did allocate enough bytes)?

I assume that the intention is to treat these as well defined accesses
(pointer is within address range), is that right?

I'm thinking of flexible array members in structs, and things like:
struct foo
{
    ...
    char var[1];
};

struct foo *x = malloc(sizeof(*x) + len);
x->var[len-1];

Best regards,
--Edwin