Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <6288137.155831275562619748.JavaMail.jira@thor>
Date: Thu, 3 Jun 2010 06:56:59 -0400 (EDT)
From: =?utf-8?Q?Ernst_Albrecht_K=C3=B6stlin_=28JIRA=29?= <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Updated: (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.atlass=
ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ernst Albrecht K=C3=B6stlin updated HARMONY-6542:
--------------------------------------------

     Summary: java.io.RandomAccessFile.seek (long pos) throughs exception o=
n calls with "pos" set to values greater then 0x7FFFFFFF  (was: java.io.Ran=
domAccessFile.seek (long pos) throughs exception on calls with "pos" set to=
 values larger then 0x7FFFFFFF)
    Priority: Major  (was: Minor)

> 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
>         Environment: 32bit Linux/windows
>            Reporter: Ernst Albrecht K=C3=B6stlin
>         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.