This value will be returned and converted to a size_t again
Correct, but this is safe, because the range was checked in the if below.
Generally, the idea is that 32-bits is just not really enough to do size accounting (even on 32-bit architectures), because some code paths may accumulate sizes over time, or multiply them with a factor, all of which may or may not overflow the limited 32-bit value.
So using 64-bit arithmetic is overall safer, and more future proof, because current and future reviewers have to think less about whether a 32-bit value may or may not overflow when doing arithmetic with it.
Obviously, many 64-bit values will need to be cast to 32-bit later on for serialization, but this is generally only done after checking their range to ensure a safe cast. For example, in this case it is:
0 if (pos.nPos + data_size > MAX_FLTR_FILE_SIZE) {
nPos and MAX_FLTR_FILE_SIZE are 32-bit values, so if data_size was also 32-bit, the sum could overflow (theoretically) and incorrectly pass the if guard. Using 64-bit values here seems safer.
I see in your branch that you want to change MAX_FLTR_FILE_SIZE to be 32-bit explicitly. However, I think it is safer to change it to 64-bit (or leave it as-is and rely on data_size being 64-bit).
