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