"H. Peter Anvin" <[email protected]> wrote:
> I have noticed that the new ...at() system calls are named in what
> appears to be a completely haphazard fashion. In Unix system calls,
> an f- prefix means it operates on a file descriptor; the -at suffix (a
> prefix would have been more consistent, but oh well) similarly
> indicates it operates on a (directory fd, pathname) pair.
>
> However, some system calls, in particular fchownat, futimesat,
> fchmodat and faccessat add the f- prefix for what appears to be
> absolutely no good reason. Logically, these system calls should be
> named chownat, utimesat, chmodat, and accessat.
>
> I understand some of this braindamage comes from Solaris, but some of
> these calls do not. We should avoid it if at all possible, and I
> would recommend at least introducing aliases with the sane names.
This has bothered me, too.
But what would the semantics be? Using an alias named `chownat'
to get lchown-like functionality (with the AT_SYMLINK_NOFOLLOW flag)
seems undesirable.
If we're considering aliases,
then how about a pair of `f'-less names for each of the f*at
names. E.g., chownat and lchownat corresponding to the use (or not)
of AT_SYMLINK_NOFOLLOW in the last parameter of an fchownat function call.
Here's some code from coreutils/lib/openat.h:
/* Using these function names makes application code
slightly more readable than it would be with
fchownat (..., 0) or fchownat (..., AT_SYMLINK_NOFOLLOW). */
static inline int
chownat (int fd, char const *file, uid_t owner, gid_t group)
{
return fchownat (fd, file, owner, group, 0);
}
static inline int
lchownat (int fd, char const *file, uid_t owner, gid_t group)
{
return fchownat (fd, file, owner, group, AT_SYMLINK_NOFOLLOW);
}
static inline int
chmodat (int fd, char const *file, mode_t mode)
{
return fchmodat (fd, file, mode, 0);
}
static inline int
lchmodat (int fd, char const *file, mode_t mode)
{
return fchmodat (fd, file, mode, AT_SYMLINK_NOFOLLOW);
}
[Note that afaik, faccessat is available only in glibc so far. ]
Unfortunately, this doesn't generalize as well to faccessat,
which has four (not just two) possible values of its last parameter.
Those correspond to settings of the AT_SYMLINK_NOFOLLOW and AT_EACCESS
bits. AT_EACCESS means faccessat checks for access by the effective IDs
rather than by the real IDs.
With faccessat, we'd need 4 different names, e.g.,
elaccessat or leaccessat
ulaccessat or luaccessat
eaccessat
uaccessat
Personally, I do find it easier to read names like lstatat and statat
with only one extra argument (the file descriptor) than fstatat (...
with 0 or AT_SYMLINK_NOFOLLOW. With fstatat uses, it seems like I always
have to convert mentally that the presence of AT_SYMLINK_NOFOLLOW means
that a particular use acts like lstat.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
