Re: g_stat() did not work for large file (>2B) under WIN32

[Tor Lillqvist <tml iki fi>]

> But I still think it's not a bad idea to make g_stat() to have the same behavior
> as stat() on Linux.

But it *has* the same behaviour, more or less, to the extent possible.
What makes you think using -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 is the "standard" thing to do on Linux? If it
was "the standard" thing one always must do, why is it then needed at
all, shouldn't it be the *non-standard* case that requires extra
compiler options? (Yeah, I am mostly just playing devil's advocate
here.)

It is not really possible to change this now. Remember that g_stat()
takes a struct stat, and we can't change what struct stat is in the
Microsoft C library. Also, I honestly don't think the Linux way to
handle this is ideal either. It is, in my eyes, a bit ugly that
compiler options affect the sizes of fields in a "standard" structure
like struct stat. If some library out of your control has struct stat
as part of its API, how can you know if that library has been compiled
with  -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 or not?

Was it really that hard to predict that in the future file sizes can
be over 2 GB back when the Linux struct stat was defined? Why didn't
they make it use 64-bit size from the beginning? For something like
Windows, or SunOS/Solaris, with much longer history, one can
understand it better.

You should know that the g_stat(), g_fopen() etc so-called gstdio
wrappers were introduced for one single reason: to make it easy to
handle arbitrary file names on Windows by offering an API that uses
UTF-8. Around that time it was becoming more and more clear that all
of GTK+ will be very UTF-8 -oriented, so it fit in nicely to use UTF-8
also for file names (and other strings passed to/from the OS) on
Windows.

In retrospect, it might have been a good idea back then to make
g_stat() take not a struct stat, but some new struct GStat type, which
then on Linux would have been identical to struct stat as it is when
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 are used (regardless if
these macro definitions would be present when GStat-using code is
compiled or not), and on Windows would have been identical to struct
_stati64.

But that can't be changed now because it would of course break stuff
horribly. And anyway, GIO is the "modern" API in GLib to get file
attributes, and it obviously uses a 64-bit size.

Maybe we could introduce a *new* function, though, g_gstat(), which
would take a GStat, defined as described above?

--tml