Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Tue, 18 Nov 2003 08:59:57 -0600 (CST) From: Brian Ford X-X-Sender: ford AT eos To: cygwin AT cygwin DOT com cc: newlib AT sources DOT redhat DOT com Subject: ftello loosing upper 32 bits via _lseek64 In-Reply-To: <3FB97CD2.8060101@redhat.com> Message-ID: References: <20031117221509 DOT GP18706 AT cygbert DOT vinschen DOT de> <3FB97CD2 DOT 8060101 AT redhat DOT com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-725123414-1069167597=:922" ---559023410-725123414-1069167597=:922 Content-Type: TEXT/PLAIN; charset=US-ASCII I know this doesn't belong on cygwin-patches anymore, but is cygwin-developers, or just plain cygwin more appropriate? On Mon, 17 Nov 2003, J. Johnston wrote: > 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? > You are correct. I was in too big of a rush to go home, and I had a bad headache. The problem actually lies at line 61 of newlib/libc/reent/lseek64r.c. When I look at the return from _lseek64 in gdb, it is correct. Furthermore, the variable being assinged to (ret) is 64 bit. But, the value it gets is truncated at the 32 bit mark. This seems to be a bit over my head. I can't see why that would happen unless it is something like an incorrect/missing prototype issue. With the maze of includes, it could take me some time to track that down. Dig, dig, dig... Ah yes, looking at the preprocessor output for that file, there is no _lseek64 prototype. Next question: How do we get one? Could someone who knows how Cygwin glues to newlib better than I take a quick look? Thanks. Test case still attached. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 ---559023410-725123414-1069167597=:922 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="x.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="x.c" I2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KI2luY2x1ZGUgPHN5cy9zdGF0Lmg+ DQojaW5jbHVkZSA8ZmNudGwuaD4NCiNpbmNsdWRlIDxzdGRsaWIuaD4NCiNp bmNsdWRlIDxzdGRpby5oPg0KI2luY2x1ZGUgPHVuaXN0ZC5oPg0KDQppbnQN Cm1haW4odm9pZCkNCnsNCiAgICBGSUxFICpmcDsNCiAgICBvZmZfdCBwLCBx Ow0KICAgIGNoYXIgYzsNCg0KICAgIGxvbmcgbG9uZyBzaXplID0gNTAwMDAw MDAwMExMOw0KICAgIGludCBmZCA9IG9wZW4oImp1bmsiLCBPX1JEV1J8T19D UkVBVCwgU19JUkVBRHxTX0lXUklURSk7DQogICAgbHNlZWsoZmQsIHNpemUs IFNFRUtfU0VUKTsNCiAgICB3cml0ZShmZCwgIngiLCAxKTsNCiAgICBjbG9z ZShmZCk7DQoNCiAgICBmcCA9IGZvcGVuKCJqdW5rIiwgInIiKTsNCg0KICAg IHAgPSBmc2Vla28oZnAsIHNpemUsIFNFRUtfU0VUKTsNCiAgICBmcHJpbnRm KHN0ZGVyciwgIiVjICIsIGZnZXRjKGZwKSk7DQogICAgcSA9IGZ0ZWxsbyhm cCk7DQoNCiAgICBmcHJpbnRmKHN0ZGVyciwiJWxseCAlbGx4ICVsbHhcbiIs c2l6ZSxwLCBxKTsNCn0NCg== ---559023410-725123414-1069167597=:922 Content-Type: text/plain; charset=us-ascii -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ---559023410-725123414-1069167597=:922--