Re: file locking problem in Java_gnu_java_nio_VMChannel_lock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 12, 2006 at 05:17:20PM -0700, Casey Marshall wrote:
> Edwin Steiner wrote:
> > On Wed, Oct 11, 2006 at 10:56:46AM -0600, Tom Tromey wrote:
> >>>>>>> "Edwin" == Edwin Steiner <edwin.steiner@xxxxxxx> writes:
> >> Edwin> The attached patch fixes this case. It is still
> >> Edwin> not safe for len > signed 32 bit.
> >>
> >> Looks ok to me, I'm going to check it in.
> >>
> >> I wrote a ChangeLog entry for you -- but please, next time, send one
> >> with a patch.  Thanks!
> > 
> > Sorry, I did not see my patch as a real solution, just as a quick fix, so 
> > I thought something else would finally be checked in. There is code
> > duplication and all values > signed 32-bit will fail, except for the
> > max long value that is now checked. However, I don't know enough about
> > classpath to solve these issues.
> > 
> 
> Are we missing a #define of LARGEFILE_SOURCE or FILE_OFFSET_BITS=64?

Yes, that might be the case. After some digging in my /usr/include, it
seems to me that

    #define _FILE_OFFSET_BITS 64

should do the right thing, at least on my system. It selects the 64-bit
versions as the default API.

I verified that -D_FILE_OFFSET_BITS=64 makes sizeof(off_t) == 8.

We need someone with configure-fu. :)

Cheers,
-Edwin



[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux