RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
Ivan Gerasimov
ivan.gerasimov at oracle.com
Tue Mar 3 08:15:24 UTC 2015
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.gerasimov at oracle.com <mailto:ivan.gerasimov at 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
>
>
More information about the core-libs-dev
mailing list