Seek issue with VS2022

[fridgemagnet3]

There's a problem with file seeking with VS2022 (possibly others) when the library is built in it's default configuration (v2.1.1). The problem appears to be related to this code within file_win32.cpp

bool
StandardFileProvider::seek( Size pos )
{
#if _WIN32_WINNT >= 0x0600 // Windows Vista or later
    return _fseeki64( _file, pos, SEEK_SET );
#else
    // cause a cache flush before using _fileno routines
    fpos_t fpos;
    if ( fgetpos( _file, &fpos ) || fsetpos( _file, &fpos ) )
        return true;
    return _lseeki64( _fileno( _file ), pos, SEEK_SET ) == -1;
#endif

When I build the library, it generates code for the 'else' part of the conditional. Then for some reason, early on whilst parsing a m4a file, 'fpos' comes back with a negative number. Things seem to work for a bit after this but eventually it throws an assertion error when reading the header.

Setting _WIN32_WINNT to be 0x600 (or higher) such that it uses _fseeki64 seems to "fix" the problem. I'd say this is someting weird with the VS runtime library, I don't see this behaviour with VS2013.

[enzo1982]

Thank you for reporting this! I can confirm the issue.

The negative fpos value is not the problem here. fpos is not supposed to be inspected by the caller and does not necessarily contain the actual file position.

The problem seems to be that calling fsetpos in recent versions of the Microsoft C runtime does not reliably flush the cache anymore.

When building with Visual Studio 2013, an older version of the runtime is linked that still performs the cache flush each time fsetpos is called.

I'll prepare a patch that will automatically adjust the value of _WIN32_WINNT depending on the Visual Studio toolchain used.

It may also be possible to dynamically load _fseeki64 and always use it if it is present. That would probably be the best solution here.

[enzo1982]

Just noticed that this is actually fixed already by commit 493187b5.

However, I already implemented code to dynamically load _fseeki64 in the meantime and will commit it. Using _fseeki64 when available should be safer than relying on rewind + _lseeki64 working.

I'll also prepare a 2.1.2 update in the next few days with this and some other fixes.

[enzo1982]

Commit 919f91eb adds the code to dynamically load the _fseeki64 function if available.

In addition, commit 37048770 adjusts the _WIN32_WINNT version according to the minimum version supported by the toolchain when compiling with Visual Studio.

[enzo1982]

Fixed in MP4v2 v2.1.2.