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(a)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 :|