Closed illwieckz closed 1 year ago
Why do we need to go out of the way for 64-bit functions anyway? It's not like anyone needs to load a 4-gigabyte image onto the GPU
Why do we need to go out of the way for 64-bit functions anyway? It's not like anyone needs to load a 4-gigabyte image onto the GPU
I don't know. But the tool was doing that so I see no reason to silently regress on that part.
This also changes the inode number in struct stat
to 64-bit. This is required on some filesystems (XFS I think) or stat
calls will fail for 32-bit programs because the inode number doesn't fit.
This also changes the inode number in
struct stat
to 64-bit. This is required on some filesystems (XFS I think) orstat
calls will fail for 32-bit programs because the inode number doesn't fit.
Ah, that's good to know! Would it be needed to set such define on Linux even when using *64
function variants?
This looks good enough so let's merge it.
@turol do you know if there would be some need to also set _FILE_OFFSET_BITS 64
on Linux for some uses case, even if using functions like fopen64
?
I don't know exactly what effect this has on 64-bit or how it affects stat64/open64 functions.
Inspecting the generated code it seems that it controls at least whether the call is to _xstat
or _xstat64
function.
crunch: use
_FILE_OFFSET_BITS 64
withfopen
/fseek
/ftell
outside of Linux.It seems to work on macOS and FreeBSD without requiring specific
#ifdef
for any them. It also works on Linux but we may still prefer*64
variants to avoid ambiguity.Note: If needed,
minizip/ioapi.h
is known to provide more compatibility code for old MSVC too, but what we have looks good enough on that part.