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@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 :|