This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: fseek064 calling fflush on Cygwin
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/