Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
6.0M1, 5.0M13
-
None
-
32bit Linux/windows
-
Patch Available
-
Moderate
Description
Dear Community
.
Calling java.io.RandomAccessFile.seek (long pos) throughs an exception on calls with "pos" set to values larger then 0x7FFFFFFF.
I checked this on Linux for the 32bit versions of the stable hy6 build (6M1) and also on the current svn trunk from yesterday (June 2nd 2010).
This issue was reported by others to also occur on Linux for the stable hy5 (5M13) build and on windows for the stable 5/6 builds.
I checked the stable 64bit version for Linux, to find the issue NOT to occur in there, seek for values greater then 2Gig worked fine there.
Investigations on the 32bit sources of the shared luni code showed a casting issue, mostly like introduced by the idea that all signed integers on the 32bit version have a maximum lenght of 32bits. This is not the case for seeking, which should work until seek distances up to 0x7FFFFFFFFFFFFFFF.
The underlying os-specific code (linux and windows) does take care of the possibility of 63bit long distances. Just a nasty casting of the distance down to 32bit somewhere a bit more upper in the calling stack makes those "long distance" calls fail.
Change this casting does it for windows.
To get things going on linux also the additional C-define "#define _FILE_OFFSET_BITS 64" needs to be set for building.
I'm not sure if I added this define for the linux build to best place possible, so please any hy-gurus out there have a look at it.
I append a patch (for Linux hy5-stable (5M13) to this posting which solves this (casting-)issue and adds the C-define. It's quite small and it should be easy to addept it to other source releases. If anyone likes I could also provide patches for the current stable hy6 (6M1) or even the current svn-trunk.
Thanks and happy hacking...
Kind regards
/a