Thanks Martin for the suggestion!
On 03.03.2015 0:08, Martin Buchholz wrote:
slightly safer (more likely to compile everywhere) might be to convert
input length into a size_t immediately and to
I'm not quite sure it would be correct.
If size_t happens to be 32-bit int, then the length could overflow,
since it represents the size of the array in bytes, while we're
operating on the the array of shorts, ints and longs.
I would feel more comfortable if length gets cast to size_t only when it
is guaranteed to be in the range (0, 1048576).
By the way, in
'java.base/share/classes/java/nio/Direct-X-Buffer.java.template' I see
this code:
public $Type$Buffer get($type$[] dst, int offset, *int*length) {
if ((*length**<< $LG_BYTES_PER_VALUE$*) >
Bits.JNI_COPY_TO_ARRAY_THRESHOLD) {
Am I correct this would cause overflow for LongBuffer.get(buff, 0, (1 <<
24)) ?
Sincerely yours,
Ivan
#define MBYTE ((size_t) 1048576)
On Mon, Mar 2, 2015 at 12:59 PM, Ivan Gerasimov
<ivan.gerasi...@oracle.com <mailto:ivan.gerasi...@oracle.com>> wrote:
Thank you Alan for review!
As you've noted, there is no need to update xxxAddr because
the position is updated during swapping copy. That looks okay
to me.
Only updating size for the last chunk is okay too, but that a
bit of coin toss as to whether to change this as the current
code is easy to read. The stale comment should be removed of
course.
I agree that readability is important.
Below is the updated webrev. I couldn't resist to making it a bit
shorter, though :)
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8074067
WEBREV: http://cr.openjdk.java.net/~igerasim/8074067/1/webrev/
<http://cr.openjdk.java.net/%7Eigerasim/8074067/1/webrev/>
I checked that the source can be built on all platforms, despite
of the warning in the comments.
Sincerely yours,
Ivan
