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

On Mon, 2011-09-26 at 08:59 +0200, Kean Johnston wrote:
> There is also a broader issue with stat. The size of struct stat can vary 
> according to what macros are defined when you include <sys/stat.h>. If you 
> have _FILE_OFFSET_BITS=64 defined your size fields are 64-bit, otherwise 
> they *can* be 64-bit but are most often 32-bit. Thus, if glib was compiled 
> without _FILE_OFFSET_BITS defined, and an application uses g_stat() but 
> DOES have it defined, you're in for trouble (and the inverse is true - if 
> glib was compiled with _FILE_OFFSET_BITS=64 and the app wasn't, the same 
> hilarity ensues).

I don't see how this would be any problem. Both the app and the library
will get the struct stat that matches what they were compiled with. The
only problem would be if you passed the struct stat between glib and the
app, but that doesn't happen as g_stat is a macro.

> On almost all UNIX systems time_t is a signed 32-bit int thus capable of 
> representing time from the epoch through some time in 2038. Windows has 
> support for 64-bit time fields which is surprisingly forward thinking of them.

time_t is typically a signed long, which is 64bit on all 64bit linux

> Since GLib is a "platform library" it would be extremely useful if 
> gstsdio.h defined a GLib version of the stat structures instead of just 
> doing "typedef struct stat GStatBuf". That structure can be consistently 
> defined, with sufficiently large data types that it will work on all 
> systems. Despire the coolness of Windows supporting time fields 64-bits 
> wide for the least amount of pain it would probably be best if the time 
> fields were left at 32-bits (although it would be really cool and forward 
> thinking if we used 64-bits), but to use 64-bit fields for all size fields, 
> and 32-bit fields for all others. That way gstdio.[ch] can be compiled in a 
> very specific way to get the information needed and then smush it into that 
> portable structure. Here's how I would define the GStatBuf data type:
> typedef struct GStatBuf {
>    guint32          st_dev;
>    guint64          st_ino;
>    guint16          st_mode;
>    guint16          st_nlink;
>    guint32          st_uid;
>    guint32          st_gid;
>    guint32          st_rdev;
>    gint64           st_size;
>    gint32           st_atime;
>    gint32           st_mtime;
>    gint32           st_ctime;
> } GStatBuf;

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.

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

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