Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <25220954.12731277283830798.JavaMail.jira@thor>
Date: Wed, 23 Jun 2010 05:03:50 -0400 (EDT)
From: "Hudson (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Commented: (HARMONY-6542) java.io.RandomAccessFile.seek
 (long pos) throughs exception on calls with "pos" set to values greater
 then 0x7FFFFFFF
In-Reply-To: <27164255.155621275561300159.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HARMONY-6542?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D12=
881622#action_12881622 ]=20

Hudson commented on HARMONY-6542:
---------------------------------

Integrated in Harmony-select-1.5-head-linux-x86_64 #38 (See [http://hudson.=
zones.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/38/])
    Add regression test for "[#HARMONY-6542] java.io.RandomAccessFile.seek
(long pos) throughs exception on calls with 'pos' set to values
greater then 0x7FFFFFFF".  Only works for unix platforms but that's better
than not having one.


> 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=C3=B6stlin
>            Assignee: Mark Hindess
>         Attachments: patch-java.io.RandomFileAccess.seek-gt2gb-hy5-201060=
3.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 oc=
cur in there, seek for values greater then 2Gig worked fine there.
> Investigations on the 32bit sources of the shared luni code showed a cast=
ing issue, mostly like introduced by the idea that all signed integers on t=
he 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 pos=
sible, 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 solve=
s this (casting-)issue and adds the C-define. It's quite small and it shoul=
d be easy to addept it to other source releases. If anyone likes I could al=
so provide patches for the current stable hy6 (6M1) or even the current svn=
-trunk.
> Thanks and happy hacking...
> Kind regards
> /a

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