On 11/14/2011 11:54 AM, Paul Eggert wrote:
> else
> {
> + /* On GNU hosts, getuid etc. can fail and return -1. On POSIX
> + hosts, such failures are not allowed and (uid_t) -1 may be a
> + valid UID if uid_t is unsigned.That doesn't read correctly. You are correct that POSIX states that getuid() cannot fail in a conforming environment (therefore, the only way that GNU getuid fails is if you have done something outside the realms of a conforming environment). However, POSIX is quite clear that chown() must honor (uid_t)(-1) as a means of not altering the uid of a file, therefore, POSIX explicitly rejects (uid_t)(-1) as a valid UID. POSIX leaves it up to the implementation whether the type uid_t is signed or unsigned, but also specifies that valid uids are non-negative integers (so if uid_t is signed, half the possible values will never be encountered as valid uids). > To handle both cases > + correctly, consider getuid etc. to fail if it returns a > + negative value. But if uid_t is an unsigned type (which POSIX permits), then it will never be a negative value. > + > + POSIX hosts should not give users a UID equal to (uid_t) -1 > + even if uid_t is unsigned, as system calls like chown would > + behave unexpectedly with such a UID, and in general coreutils > + therefore does not support such a UID. However, 'id' makes a > + special attempt to handle it, if only to help people diagnose > + the problem. */ > + > euid = geteuid (); > - if (GETID_MAY_FAIL && euid == -1 && !use_real > + if (euid < 0 && !use_real That is, how can this work? On systems where uid_t is signed, it makes sense, but on systems where uid_t is unsigned, this will always be false (and probably trigger a gcc warning), and still fail to catch the (uid_t)(-1) case that we are trying to diagnose. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
