(fhandler_base::lseek): Include high order bits in return.

J. Johnston jjohnstn@redhat.com
Tue Nov 18 13:36:00 GMT 2003


Brian Ford wrote:
> On Mon, 17 Nov 2003, Brian Ford wrote:
> 
> 
>>On Mon, 17 Nov 2003, Corinna Vinschen wrote:
>>
>>
>>>On Mon, Nov 17, 2003 at 03:40:46PM -0600, Brian Ford wrote:
>>>
>>>>On Mon, 17 Nov 2003, Brian Ford wrote:
>>>>
>>>>
>>>>>This bug fix got our app past its first problem with > 2 Gig files, but
>>>>>then it tripped over ftello.  I'm still trying to figure that one out.
>>>>>
>>>>>It looks like it got a 32 bit sign extended value somewhere.  Any help would
>>>>>be appreciated.  Thanks.
>>>>>
>>>>
>>>>Well, that somewhere is ftello64.c line 111.  fp->_offset has a 32 bit
>>>>sign extended value.  Anybody know how it got there?
>>>
>>>That can't be it.  fp is of type FILE which is actually mapped to
>>>__sFILE64 in 64 bit case.  See newlib/libc/include/sys/reent.h.
>>>_offset is of type _off64_t there.
>>>
>>
>>I think you misunderstood.  fp->_offset is a 64 bit type, but at the
>>ftello call in question, it contains a value that must have come from a 32
>>bit sign extension.  That's why I asked for help, because I have to figure
>>out what/who put it there.
>>
> 
> I have attached a test case that shows the problem.  It is on line 58 of
> lseekr.c.
> 
> I can't seem to find the actual problem tonight and I'm tired so I'm going
> home.
>

IIRC, Cygwin redirects your calls to the appropriate 64-bit I/O code and thus, 
should not be allowing you to call lseek and should instead redirect your call 
to lseek64.  Now, there isn't currently an lseek64 in the libc/syscalls 
directory which contains syscall wrappers used by Cygwin.  Corinna, if I add the 
appropriate wrappers, would that help or does Cygwin provide its own wrappers?

-- Jeff J.




More information about the Newlib mailing list