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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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

Nicolas