[core] `GetFileLength()` overflows with file larger than 2GB

[michelelorusso05]

The IO method GetFileLength returns the size of a given file stored in an int variable. Since it's only an unsigned 32 bit number, the function works properly only with files smaller than 2147483647 bytes. Any method that operates on file sizes should return an unsigned long.

[orcmid]

That's a problem. There is no requirement that unsigned long have a larger maximum size than unsigned int, which is also required to have the sane maximum, at least 2147483647. For more you need unsigned long long and a hefty 0xffffffffffffffffui64 minimum maximum.

These values for <limits.h> are established in ISO C11. I would not expect them to have changed since.

[michelelorusso05]

Yeah, you're right. I meant that an unsigned 64 bit integer would be more suitable, and on most modern compilers an unsigned long is just that. The function should return a uint64_t.

[orcmid]

Oh Oh. Well, I looked at GetFileLength() in rcore.c and there are many problems.

First, it opens the file named and if that fails it returns 0 (rather than EOF or something).

Secondly, it seeks to the end of the file using fseek(file, 0L, SEEK_END) without checking for any error case.

Finally it returns size from

size = (int) ftell(file);

There are three problems here. ftell returns a long, not an int. There is also some question about whether the position of the end of the file is the same as the size of the file. There is also no failure check on the ftell result.

I suppose we can confirm the answer the second question by doing an

fseek(file, 0L, SEEK_SET);

and seeing what an ftell returns after that.

For files longer than INT_MAX or LONG_MAX another solution is required.

The Microsoft <stdio.h> includes _ftelli64 which handles the situation by presumably returning an int64. That's definitely not C99 or C11, and must be considered a non-ISO extension unless something shows up in C17 or C23. I suppose that means Microsoft also has an int64 version of fseek and indeed it does. :).

[raysan5]

@michelelorusso05 @orcmid that function was added for my convenience and I'm aware of its deficiencies.

Also, in raylib I try to avoid stdint.h types and just use the language provided ones. In any case, it can be updated to return a long instead of int or just add some notes about the limitations of this function.

Is there a better multiplatform approach to get filesize than using fseek()/ftell()?

[michelelorusso05]

As far as I am aware, fseek/ftell is the most convenient way, cross-platform speaking. As for the returned type, since long can be either 32 bit or 64 bit based on the implementation, employing an unsigned long long can ensure an at least 64 bit value.

[raysan5]

@michelelorusso05 On raylib all data-size-related variables, even the referred to file data, are int or unsigned int, changing this function to unsigned long long will break consistency with all the other functions just to cover a specific use case that probably not many users will need.

In any case, it can be checked inside and if the file is bigger than 2/4GB return 0 and TraceLog() a warning message, that's the usual mechanism used by raylib on those situations.

This issue is somewhat related to #3168.

[michelelorusso05]

I guess that the function should be left as is, for the sake of consistency. However, as you said, the docs should be updated to describe this behaviour.

[orcmid]

@raysan5

Is there a better multiplatform approach to get filesize than using fseek()/ftell()?

It depends how widely available stat is. This provides size information from the file-system directory and not by seeking to the end. There are problems for non-binary text files having to do with \n and \0x1A in some files.

There seem to be flavors that address the need for very large file sizes.
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions.

[raysan5]

Reviewed, added better documentation and tracelog