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.


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.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Attachment: x.c
Description: Text document


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