Brian Ford <Brian.Ford <at> FlightSafety.com> writes: > > I have an application that is having a 64-bit file I/O problem with Cygwin > 1.7.0 CVS that it did not have with Cygwin 1.5.18. I have tracked it > down to the following series of calls in newlib: > > #0 fflush (fp=0x7b5a764) > at ../../../../../cygwin/newlib/libc/stdio/fflush.c:124 > #1 0x611049ff in _fseeko64_r (ptr=0x16cbd008, fp=0x7b5a764, > offset=27368291304, whence=0) > at ../../../../../cygwin/newlib/libc/stdio64/fseeko64.c:326 > #2 0x61104edf in fseeko64 (fp=0x7b5a764, offset=27368291304, whence=0) > at ../../../../../cygwin/newlib/libc/stdio64/fseeko64.c:350
Thanks for the report. Prior to a couple months ago, this wasn't a problem, because fseek(f,0,SEEK_END) was mistakenly succeeding on large files. This is fallout from my recent patch to make fseek properly fail with EOVERFLOW; but as you discovered, a side effect is that fflush is no longer seeking to the end the way it should be when it ignores the EOVERFLOW. > > So, it would seem that fflush is not 64 bit safe and fseeko64 should not > be calling it, but I'm not sure how to fix it. > > Any suggestions? > In environments with large files, fflush needs to check for __SL64, in which case it should call fp->_seek64, not fp->_seek. That clinches it - I need to complete my patch to make fflush reentrant and 64-bit safe. I'll hopefully have something by early next week. -- Eric Blake -- 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/
