(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