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

[Kean Johnston <kean johnston gmail com>]

> time_t is typically a signed long, which is 64bit on all 64bit linux
> versions.
Even more good reason to standardize then.

> I don't see what advantages this gives you. It will break all existing
> code that uses g_stat and struct stat, you can't share GStatBuf with
> other struct stat using code, you can't access extensions like
> nanosecond mtimes, it doesn't have things like blocksize and st_blocks
> which means you can't calculate actual space used.
So easily solved. Call the damned thing g_statfile() and have the structure 
be GFileStat. Something else. The Windows stat structure doesn't have block 
size and st_blocks anyway so again your code needs to become poluted with 
ifdefs. We can add the block size and number of blocks, and on Windows we 
can either find another API that gives us the same information of set the 
block size == file size and the number of blocks to 1 so that the code 
presents a uniform interface. It is *EXACTLY* because of all of these 
differences that having a wrapper is useful.

> Also, we *do* have an abstraction that lets you write portable code. Its
> called GFileInfo. g_stat is by its nature a lowlevel unix-like call, it
> was added mainly as a quick way to port unix code to windows. So,
> introducing our own copy of struct stat on windows might make sense
> (with its c runtime library issues), but we don't want to change it on
> unix.
Only if you define "UNIX" as "Linux". OSX has other fields Linux doesn't. 
Some UNIX variants have 16-bit uid_t's others have 32. Some have as low as 
16-bit ino_t's others have 64. There are all KINDS of ways in which it 
differs. Offering a portable, no-ifdefs-required, 
suitably-large-sized-to-accomodate-everyone structure ... yes *STRUCTURE* 
that all code can use completely portably without having to worry about 
anything ... SURELY you can see the value in that? GFileInfo from GIO? You 
have GOT to be kidding me? As a replacement for stat()? When I want to look 
up a file attribute I have to go through hash table lookups for attributes 
and a completely open-ended size (GArray *attributes) and all that parent 
class and instance overhead - versus having a single structure I can 
sizeof() and write to a file? In what universe is that a better approach?

GLib does plenty of abstractions of things that you could just use the 
native API for. Like g_malloc(). You could just use malloc(). But there are 
variances on how malloc() behaves so you wrap it to get consistent 
behaviour so that everywhere you use g_malloc(0) you know exactly what you 
are getting. You wrap printf because not all printf's are alike. stat() is 
just the same. It needs wrapping because not all stats are the same. It can 
be trivially done. It can be done in such a way that it doesn't break any 
ABIs or even API's. What's the problem?