[foreign] RFR : Move array-like methods from Pointer to Array

[Jorn Vernee]

<snip>

>>> And this would generally applicable to both arrays and pointers. No
>>> guesswork involved, users iterating on pointers will have to provide
>>> an explicit termination condition; if they get it wrong, they will 
>>> get
>>> some exception when dereferencing the wrong memory location.
>> 
>> Well, for native-allocated pointers this will invoke undefined 
>> behavior or possibly crash the VM (or enable access to VM internals? 
>> I'm not sure what security is in place there currently).
> 
> A possibility there would be to avoid using EVERYTHING as a backing
> region. That is, the binder could, in principle, generate regions that
> are small enough only to contain the region that we actually want to
> access (e.g. starts at base address , ends at base address + pointee
> layout size). If the client is not happy with that and knows that the
> pointer is a pointer to some kind of a buffer, perhaps an (unsafe?)
> operation could be provided to relax the memory region boundaries
> beneath the pointer.

That's a possibility. But that would practically mean that you'd always 
call this operation before calling elements() or offset(), possibly as 
part of the implementations of those methods. So I don't see how you 
gain any net safety by doing that.

Pointer::offset is this 'unsafe' operation in my current patch, but the 
way it works things like long[] and ByteBuffer are currently still 
guarded by a bounds checks, because they use an actually bounded memory 
region.

> But overall I think we should strive for the 'no VM crashes if you are
> only using the safe API' (although we don't have to get there in one
> step).

Also one of the reasons I wanted to remove Pointer::elements ;)

<snip>

Jorn