Date: Thu, 29 Aug 2002 10:35:31 +0300 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: hackers@freebsd.org Subject: chown() vs. setfown() prototype in vfs_syscalls.c Message-ID: <20020829073530.GB33894@hades.hell.gr>
next in thread | raw e-mail | index | archive | help
Hello,
A friend asked me why he was getting warnings about conversion of
unsigned to signed, when calling chown() with:
chown("/dev/null", -1, -1);
The manpage of chown has a prototype of:
int
chown(const char *path, uid_t owner, gid_t group);
But the manpage mentions that (uid_d)-1 is the right value for a chown
operation that wants to leave the user part of the owner:group set
unchanged.
After a bit of research he found that the definition of uid_t was
(unsigned int) and that's why -1 was giving him warnings. But the fun
doesn't stop there... The implementation of chown in vfs_syscalls.c
uses `int' as the type of the two uid_t/gid_t arguments in the *uap
argument, and then calls setfown() which accepts uid_t and gid_t !!!
Then setfown() copies the values in a `struct vattr' at the va_uid and
va_gid members, which are also uid_t and gid_t.
The only place where the uid & gid arguments of chown() are int and
not uid_t and gid_t is in the prototype of the system call itself.
Is this really necessary? Is there a reason behind it?
--
FreeBSD: The Power to Serve -- http://www.FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020829073530.GB33894>