This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]