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@xxxxxxxxxx> 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 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list