You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Mark Hindess (JIRA)" <ji...@apache.org> on 2010/06/04 10:05:00 UTC

[jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF

    [ https://issues.apache.org/jira/browse/HARMONY-6542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875523#action_12875523 ] 

Mark Hindess commented on HARMONY-6542:
---------------------------------------

Thanks for this contribution.  Could you please complete ICLAs and ACQs as mentioned at:

  http://harmony.apache.org/contribution_policy.html

Sign them, scan them and email them to private@harmony.apache.org.

Thanks,
 Mark. 


> java.io.RandomAccessFile.seek (long pos) throughs exception on calls with "pos" set to values greater then 0x7FFFFFFF
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-6542
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6542
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>    Affects Versions: 6.0M1, 5.0M13
>         Environment: 32bit Linux/windows
>            Reporter: Ernst Albrecht Köstlin
>         Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-2010603.txt
>
>
> 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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.