Ray Satiro
raysa****@yahoo*****
Thu Apr 12 16:23:12 JST 2018
ForkI did a search and found that it was addressed [1] and the solution was
at one point _lseeki64:
__int64 _fseeki64( FILE *stream, __int64 offset, int whence )
{ return _lseeki64( _fileno( stream ), offset, whence ); }
My problem with that is it's blind to the FILE buffering. Assume FILE *f
opened rb with contents "abcdef":
printf("%c\n", fgetc(f));
printf("%c\n", fgetc(f));
_lseeki64( _fileno( f ), 4, SEEK_SET);
printf("%c\n", fgetc(f));
The third fgetc call is going to get the third character 'c' and not the
fifth 'e'. If I put an fflush after the lseek I will get the fifth
character, but according to msdn fflush is documented to not do that and
explicitly retain the FILE buffer for files opened for just read [2].
I am thinking about using fseeko64 and ftello64. That looks ok except
for ftello64 I might need fflush needed prior to call on write streams
[3][4]. Are there any downsides / bugs in the o64 functions? How are you
guys handling 64-bit offsets in FILE when building a program for >=XP ?
Thanks
[1]: https://sourceforge.net/p/mingw/bugs/2021/
[2]: https://msdn.microsoft.com/en-us/library/9yky46tz.aspx#Anchor_2
[3]:
http://mingw.5.n7.nabble.com/ftello64-returning-wrong-values-td1097.html
[4]:
https://cboard.cprogramming.com/windows-programming/68331-fseek-vs-fseeko64;-whats-difference.html