|Re: [hatari-devel] Using ftello/fseeko instead of ftell/fseek for large file support|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 23/08/2017 à 17:22, Thorsten Otto a écrit :
On Mittwoch, 23. August 2017 14:56:27 CEST Nicolas Pomarède wrote:
Shouldn't we use fseeko/ftello which uses a "off_t" type and can handle
64 bit file size, instead of the older fseek/ftell which can be limited
to 32 bits / 2 GB ?
You usually only need that on 32bit hosts. On 64-bit hosts, the default
interface already uses long. which should be 64bit (unless for braindamaged
win32, but things are there different anyway). Also, even for 32-bit hosts,
you usually can enforce the interface to use 64bit file pointers by using
_LARGEFILE_SOURCE and _FILEOFFSET_BITS=64 without having to change your code.
Beside that, it is really only important for things like you mentioned
(accessing the recorded avi file). For the gemdos emulation, it is irrelevant,
since neither mint nor TOS can handle 64bit file offsets.
I agree that if emulated HD file is less than 2GB, then fseek/ftell is
the same, but still, several posix doc strongly suggest to always use
fseeko/ftello (as well as off_t instead of long int) and then it will be
the underlying library that will either map to fseek/ftell or
And as we build 32 bit and 64 bit versions of Hatari for Windows using
mingw, I think it would be safer to always use fseeko/ftello (and also
more consistent as in some files both are sometimes mixed).
Also see that file.h already has a define to map fseeko/ftello to
fseek/ftell in case cmake didn't detect a compliant fseeko/ftello.
So, I think it would be safe to use fseeko/ftello everywhere, but as I
don't use IDE drives or some other parts wher it's used, I'd rather not
change it myself as I don't have a test case to check it still works :)