[llvm-commits] [llvm] r77460 - /llvm/trunk/docs/LangRef.html

[Dan Gohman]

On Aug 18, 2009, at 12:08 PM, Török Edwin wrote:


> On 2009-08-18 21:07, Dan Gohman wrote:
>
>> On Aug 18, 2009, at 10:38 AM, Duncan Sands wrote:
>>
>>
>>
>>
>>
>>
>>
>>> Hi Dan,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Add one-past-the-end language to the inbounds keyword.
>>>>
>>>>
>>>>
>>>>
>>>>
>>> is this useful for LLVM?  Also, I hear that C has a rule like this
>>>
>>> for arrays, however I think in that case the address of the array
>>>
>>> element one off the end is valid, but that may in fact be many
>>>
>>> bytes off the end if the array element is large.  It's not clear
>>>
>>> from your wording whether you mean one byte off the end is ok,
>>>
>>> or something closer to C.
>>>
>>>
>>>
>>
>>
>> The one-past-the-end rule is entirely motivated by the need to
>>
>> support C, and programming models that lower to C-like semantics.
>>
>> From my reading of the standard, only one byte of address space
>>
>> is required to satisfy C's one-past-the-end rule.
>>
>>
>>
>> If I've misinterpreted the standard, or if there are programming
>>
>> models which require more than one byte and which could be
>>
>> accommodated by a reasonable change, I'm interested in hearing
>>
>> about it.
>>
>>
>>
>
> There are programs which read 2 bytes for 2-byte aligned addresses,
> 4-bytes for 4-byte aligned, etc. and rely on the fact
> that even though it reads uninitialized bytes, the memory is still  
> valid
> (since memory is allocated in pages).
> I think this is why valgrind has the '--partial-loads-ok=yes' flag.
>
> Such code doesn't conform to the C standard strictly, however I  
> remember
> doing that some glibc version used it in strcmp & friends, at least on
> x86-32 (not sure if it was in assembly code or C code, but it wouldn't
> surprise me if it were C code).
>
> I think allowing to read at least min(AlignOf(ptr),16)-1 at the end of
> an array/string is reasonable.
> Actually the computer pointer's start address is inbounds according to
> your rules, but the load/store itself is not.
> So how about allowing to read at most 16 bytes whenever the start
> address is inbounds?

This is an interesting problem, though it happens to be outside
the scope of the inbounds keyword. The inbounds keyword just says
that the address itself (as well as any implicit intermediate
addresses) will stay within the range of the object plus one byte
past the end. It doesn't say anything about what can be done with
such a pointer value.

Perhaps the problem can be solved by adding some wiggle room to
the definitions of alloca and malloc, so say that they may allocate
a target-dependent amount of additional space beyond what is
requested.

Dan