Re: _wstat on Windows (actually stat stuff in general)

[Alexander Larsson <alexl redhat com>]

On Wed, 2011-09-28 at 10:00 +0200, Kean Johnston wrote:
> 
> > This means that there is an awful lot of valid existing code (including
> > within GLib itself) that looks like this:
> >
> > {
> >    struct stat buf;
> >
> >    g_stat (filename,&buf);
> > }
> >
> > which (if I understand your proposal correctly) would be badly broken.
> That code would of course change to
> {
>    GStatBuf buf;
> 
>    g_stat (filename, &buf);
> }

It would be a break in source-compat, which we can't just do. Glib is an
API stable library used by thousands of other libraries and apps. 

> The code wouldn't be broken at all. In fact it would be less broken. If, 
> for example, GLib wasn't compiled with _FILE_OFFSET_BITS=64 then 
> internally, all of its usage of g_stat() can only deal with 31-bit file 
> sizes. User code using GLib compiled WITH that set will support file sizes 
> with 63 bits.

I don't understand why you keep bringing this up. glib has
AC_SYS_LARGEFILE in configure.ac, so it will never be built with
anything but 64bits internally.

> Almost all of the functions currently "wrapped" in gstdio.h are problematic 
> with LFS. On Linux they are currently just macros. 

They are problematic due to LFS being problematic, but that is just how
unix works. If you want to work with other libraries etc on the lower
level you have to be aware of this. If you don't want that, use the
proper glib i/o abstractions in GIO that are not using anything like
struct stat.

> That supports the vast majority of the code out there that is UNIX-centric 
> and supports the notion of a 31-bit time field measured as seconds since 
> the epoch of Jan 1 1970. But code that wants higher precision can use the 
> 64-bit variants on systems that provide it and simply multiply out the 
> 32-bit ones to give usable values on those that don't.

All 64bit linux arches uses 64bit signed time_t, and its in seconds.
Higher precision timestamps are done in linux by introducing separate
nanosecond fields in struct stat. This is all transparently handled by
GIO if you just use GFileInfo.

> Note that on Windows the 64-bit time fields are just more seconds since the 
> Epoch, with an upper limit of Dec 31 23:59:59 3000. If we decide that the 
> 64-bit time field is really nanoseconds since the Epoch (a much more usable 
> value IMHO) then it can represent dates up to some time in the year 2262. I 
> don't think it matters what it represents as long as we define it. If GLib 
> only breaks in the year 2262 I'm quite Ok with that :-)

Of course we can't just make time_t be nanoseconds, that would break a
lot of other functions that expect it to be in seconds.