Re: [hatari-devel] Using ftello/fseeko instead of ftell/fseek for large file support

[ Thread Index | Date Index | More 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 fseek64/ftell64.

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 :)


Mail converted by MHonArc 2.6.19+