AT_EMPTY_PATH and NULL

AT_EMPTY_PATH and NULL

> One might think that it makes no sense to even look at the path when the user has provided a flag (AT_EMPTY_PATH) that says there is nothing to be seen there but, as Al Viro pointed out, POSIX mandates this behavior.

I think this is a misreading of Viro's (terse) message. He doesn't say anything about POSIX, the Linux man page says that AT_EMPTY_PATH is a non-portable Linux extension, and just to be sure I don't see it in POSIX at all.

I think what he meant is that Linux itself effectively mandates this behavior, in that the current implementation of fstatat(fd, NULL, &stat_buf, AT_EMPTY_PATH is to return -EFAULT, and so userspace libraries like glibc don't have the option of setting it to NULL. That is, the problem is not that glibc is being weird by passing a non-NULL pointer to an empty string that the kernel has to go look at, the problem is that glibc has no choice but to pass a non-NULL pointer to an empty string.

But it seems to me (as a non-expert) that this is something Linux could relax - if you notice that the pointer is NULL, check for AT_EMPTY_PATH before throwing -EFAULT. It wouldn't help glibc for a long while, but it would be worth doing for several years from now, when glibc has inevitably dropped support for existing kernel versions for other reasons.

To the more general point, that the kernel shouldn't be looking at the pointer at all when AT_EMPTY_PATH is specified even if it's non-NULL, as the parent messages in that subthread point out, the kernel defines a specific non-error behavior for that case, which is to ignore AT_EMPTY_PATH and actually use the provided path, and that behavior could not be changed without technically breaking backwards compatibility for userspace - even though it's hard to imagine that anyone is relying on it. But I believe an error case (getting -EFAULT when passing NULL) can be turned into a non-error case without violating the kernel's promises about breaking userspace.