size_t is always correct for the size of memory objects, but it's 32-bits on win32 32-bit builds, which means it's too small for the size of filesystem objects.

size_t is 64 bits on 32-bit *nix systems as long as large file support is enabled (I think it always is).

Perhaps we should just use gint64 for all functions related to the filesystem? It'd be (maybe?) less confusing.

This looks good! I'll test this out on Windows later.

We probably have some other int32 limits still

I think clang-tidy's cppcoreguidelines-narrowing-conversions check might catch such things. Here's the output of that check over the entire project:
https://gist.github.com/kleisauke/9025c3564d3aec17496bd21d675908fb

Though, that could also generate false-positives, for example:

../libvips/foreign/archive.c:180:33: warning: narrowing conversion from 'int' to signed type 'char' is implementation-defined [cppcoreguidelines-narrowing-conversions]
  180 |         char compression_string[2] = { '0' + compression, 0 };
      |                                        ^

compression is already limited to [0,9] when it reaches there.

It looks like vipssave uses write_vips in generate.c instead.

Applying the same fix on that function (see e.g. commit kleisauke@af7c7bc) fixes the test case mentioned in #3918 (reply in thread) on my Windows 11 PC.

$ vips black x.v 1400000 10000 --bands 3 --vips-progress
vips x.v: 1400000 x 10000 pixels, 24 threads, 1400000 x 1 tiles, 512 lines in buffer
vips x.v: done in 18.5s
$ (Get-Item x.v).Length
42000002024

BTW, should this PR target the 8.15 branch instead?

Targeted against the 8.15 branch, included commit kleisauke@af7c7bc and added a changelog note to save you some work.

@pdbourke, I credited you in the changelog, I hope that's OK.

Ah thank you for fixing this Kleis. It looks great, let's merge.

I merged to master as well.