Make the VQA seek command's origin explicit

[mischa85]

VQACMD_SEEK carries lseek's origin in its buffer argument, but the comment in both stream handlers said "Buffer has no meaning here", and the origin was spelled five ways across 15 call sites: SEEK_CUR, SEEK_SET, NULL, 0 and (void *)1. All of them now name the constant. The origin is also taken back through intptr_t rather than int, which truncated on a 64-bit target.

Behaviour preserved: SEEK_SET is 0 and SEEK_CUR is 1, so every rename keeps the value it had.

[Krisztiaan]

Nice, just an extra step suggested

[MahBoiDeveloper]

What is the purpose of this cascade cast if you can make a specific reinterpret_cast<int>(buffer);?

[mischa85]

That won't compile on a 64-bit target. It only compiles on win32 because a pointer there is 32 bits.

So it would become static_cast<int>(reinterpret_cast<std::intptr_t>(buffer)) if we want to avoid C-style casts...

[MahBoiDeveloper]

So it would become static_cast<int>(reinterpret_cast<std::intptr_t>(buffer)) if we want to avoid C-style casts...

Em, no, 1 specific c++ cast static_cast<int>(buffer) is enough.

[ZivDero]

The problem here is that on x64 this will become a warning, likely https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4311?view=msvc-170

[MahBoiDeveloper]

What is the purpose of this function if its code just return the void pointer as int (even not int32_t)

[mischa85]

It returns int because that's the origin parameter of lseek and FileClass::Seek. int32_t is a typedef for int on both MSVC and clang, so that would change the spelling and nothing else, while no longer matching the API it feeds.

The smell is real though: the protocol hands you an integer in a pointer parameter, and a decoder is the best we can do without changing the protocol.