Closed GoogleCodeExporter closed 9 years ago
Hi Jay,
Thanks for your interest in BridJ and for your proposal.
The problem here is that there are two types of array lengths in play :
- java arrays (which length *has* to be int, because of new Object[int] / new
int[int] and Object[].length), returned by Pointer.getArray(int),
.getInts(int)...
- native arrays (which are of length size_t, so they must be represented as a
Java long), declared in the @Array annotation and stored in the struct
representation (StructIO.FieldDesc.arrayLength...), which help define pointer
bounds information (Pointer.getValidElements()...)
Then there are buffers, which have long lengths (see
Pointer.getIntBuffer(long)...).
I believe this is all technically consistent, even though it's indeed a shame
we can't use a single type for it all (with 64 bits JVMs that can deal with
dozens of gigabytes of RAM, it's a pity that Java arrays can't have more than 2
billion elements !).
I don't feel like setting all int values to longs either, as people might be
tempted to ask for arrays of length Integer.MAX_VALUE * 2 and we'd have to
check more bounds...
If you find other places where the int/long logic is indeed flawed, please let
me know.
Cheers
--
zOlive
Original comment by olivier.chafik@gmail.com
on 15 Mar 2011 at 10:56
Original issue reported on code.google.com by
frac...@gmail.com
on 15 Mar 2011 at 6:04Attachments: