Re: Glib: a Win32 discussion

[Alexander Larsson <alexl redhat com>]

On Sun, 2011-04-10 at 08:12 +0200, Kean Johnston wrote:
> On 4/7/2011 4:29 PM, Colin Walters wrote:
> > If your application deals with uids, I think you're going to end up
> > with platform-specific code; the complexities around identity are just
> > too high.  That goes doubly for inode numbers, which - why would you
> > care unless you're a backup app, and then you're *definitely* going to
> > get into platform specific stuff.
> In the context of stat, I disagree. Let's suppose you were making a 
> new-fangled version of tar. Forget for the moment that the specification 
> for tar may impose limitations on how many bits wide uid/gid's are. You 
> want your code to be as minimally system-dependent as possible, so you use 
> glib. If glib provides its own GlibStat structure, and the elements in that 
> structure are sufficiently wide for all current platforms and reasonable 
> use, this is useful. That program needs to know if two files are the same 
> so it checks on inode numbers and only includes the body of the file once 
> in the archive. So far, nothing particularly system dependent there. If you 
> *DO* need system dependent stuff, *then* you can use struct stat (or 
> whatever structure you like), with suitable conditionals protecting that 
> code, but the average code path that uses struct stat to check for minimal 
> information such as file size, last modification time and occasionally 
> ownership (frequently just checking to see if uid/gid are 0) having a 
> platform-independent structure is a big win for portability.

glib already has a GlibStat structure, its called GFileInfo, and its
properly abstracted and extendable. It also has a platform independent
solution to the "are these two files the
same" (G_FILE_ATTRIBUTE_ID_FILE).

struct stat is very ugly even on unix (with multiple versions depending
on defines and suchlike). Its also has many nonstandard extensions on
different unixes. Trying to expose a cross platform direct
representation of this is double pain, pain for us having to implement
it, and pain for users having to continue use a crappy api. We should
just get rid of all uses of stat in our higher level code (using proper
abstractions in glib).

glib (via gio) also has all sort of i/o abstractions replacing all
interesting parts of stdio (and if something is missing we should add
it).

So, ideally all apps and libraries above glib should be using gio for
all i/o, and not stdio (or gstdio).

However, I don't think we should remove gstdio from glib as it is a very
useful way to quickly get unix specific code "ported" to win32. This is
a good initial step to get something running. Later the stdio part can
be removed as things are cleaned up. If we manage to get all the stack
to not use gstdio, then the crt problem (at least wrt stdio/fds) is
"solved", as long as you manage to get a glib build that uses
msvcrt.dll.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a fast talking alcoholic paranormal investigator on his last day in the 
job. She's an elegant red-headed former first lady from a different time and 
place. They fight crime!