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

time_t is typically a signed long, which is 64bit on all 64bit linux
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
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?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]