Re: openat/fstatat functions implementation

[seebs%seebs.net@localhost (Peter Seebach)]

In message <200909171730.NAA02427%Sparkle.Rodents-Montreal.ORG@localhost>, der 
Mouse writ
es:
>As Thor said, the names suck; fstatat sounds like an -at version of
>fstat, which it isn't.  (Thor's implicit suggestion of following the
>paradigm implicit in fchroot won't work, though; that would lead to
>fopen and fstat, each of which already exists with other semantics.)

Just to be picky:

There is already an fstatat in the wild:

NAME
       fstatat - get file status relative to a directory file descriptor

SYNOPSIS
       #include <sys/stat.h>

       int fstatat(int dirfd, const char *path, struct stat *buf, int flags);

DESCRIPTION
       The  fstatat() system call operates in exactly the same way as stat(2),
       except for the differences described in this manual page.

       If the pathname given in path is relative, then it is interpreted rela-
       tive  to the directory referred to by the file descriptor dirfd (rather
       than relative to the current working directory of the calling  process,
       as is done by stat(2) for a relative pathname).

       If  the  pathname  given  in  path is relative and dirfd is the special
       value AT_FDCWD, then path is interpreted relative to the current  work-
       ing directory of the calling process (like stat(2)).

...

I would tend to recommend that we not use that name unless we use basically
the semantics of the existing one.

Despite the fact that:

>I disagree that it's reasonable to call them thread-safe versions of
>open and stat/lstat (*not*, incidentally, fstat; fstat does not need an
>-at version, since it does not take a pathname).

... as you note, naming it "fstatat" was just plain stupid.  (I reserve the
right to retract that accusation if someone can give me a coherent reason
for the "f" in that name.)

>But if you want to do it more generally, you could do much better than
>this.  This way leads, ultimately, to an -at version of each syscall
>that takes, or can take, a pathname, which is just silly.

That's pretty much what happened in Linux-land.

openat64_2()

(no, really)

>I'm not sure what would be best.  But I'd much prefer to see this done
>right than kludged.  (Of course, POSIX is a sufficiently holy document
>that it will probably be followed even when it's wrong, rendering that
>point moot, but that doesn't mean we can't do better _also_.)

Heh.

-s