[libvirt] PATCH: Latest MinGW patches

Daniel P. Berrange berrange at redhat.com
Thu Sep 4 10:15:37 UTC 2008


On Thu, Sep 04, 2008 at 11:09:49AM +0100, Richard W.M. Jones wrote:
> On Thu, Sep 04, 2008 at 11:56:44AM +0200, Jim Meyering wrote:
> > "Richard W.M. Jones" <rjones at redhat.com> wrote:
> > > On Thu, Sep 04, 2008 at 08:24:14AM +0200, Jim Meyering wrote:
> > >> Instead of adding the #if/else blocks above,
> > >> how about adding these in some header file?
> > >>
> > >> #ifndef HAVE_GETGID
> > >> static inline gid_t getgid (void) { return 0; }
> > >> #endif
> > >>
> > >> #ifndef HAVE_GETUID
> > >> static inline uid_t getuid (void) { return 0; }
> > >> #endif
> > >
> > > Hmmm ...
> > >
> > > It's a bit unexpected to have fundamental syscalls like getuid()
> > > implemented as macros which can return 0 ...
> > 
> > Why?
> > If those functions don't exist, this supplies replacements
> > (functions) that have the same semantics as the code in
> > Dan's patch: i.e. pretend UID==0 and GID==0.
> > 
> > but with far fewer cpp directives.
> > 
> > Doesn't it do the right thing?
> 
> It's just a bit worrying that people might use getuid/getgid expecting
> them to return useful values under Windows, whereas in fact they would
> be 'silently' returning 0.

Yes this is a valid point - but not in the context of this code. This
is in the XML parser code for storage APIs - this code couldn't care
less whether getuid()/getgid() is returning 0 all the time or not - it
is merely passing this data into the XML. The point where the uid/gid
field in ths XML / struct is actually used is application code, external
to libvirt  & they're the ones who would need to know that MinGW has
special semantics in this area. So whether we #ifdef inline to storage_conf
or create dummy functions in util.h doesn't impact/help external apps.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




More information about the libvir-list mailing list