questions following upcoming POSIX issue 8 release

[Eric Blake]

Hello glibc and gnulib folks,

This email is somewhat of a grab bag of topics, all related to open
bugs on the Austin Group bug tracker for issues in POSIX that will
need some attention once the upcoming Issue 8 release of POSIX is
stabilized.  If you would like to reply on a particular topic directly
in the Austin Group bug database, that might be easiest; but you can
also ask me to copy-and-paste comments around to the right audience.

- https://austingroupbugs.net/view.php?id=618
wants to change requirements for isatty() and friends to be required
to set errno on failure (right now, there is no obvious way to tell,
using only the standard, if a failure even happened); but the Austin
Group would like a wider sampling of what existing libc
implementations do.  If you could run this program on various systems
and report, that would be helpful:

#define _GNU_SOURCE
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#include <fcntl.h>
#include <string.h>

int main() {
    int fd = open(".", O_RDONLY);
    errno = 0;
    ptsname(fd);
    printf("%d %s\n", errno, strerror(errno));
    errno = 0;
    unlockpt(fd);
    printf("%d %s\n", errno, strerror(errno));
    errno = 0;
    grantpt(fd);
    printf("%d %s\n", errno, strerror(errno));
    return 0;
}

On glibc 2.39 atop Linux 6.8.11 (a Fedora 40 installation), I get:
25 Inappropriate ioctl for device
22 Invalid argument
22 Invalid argument

that is, ENOTTY for ptsname(), and EINVAL for unlockpt() and grantpt().

- https://austingroupbugs.net/view.php?id=1633
The bug mentions both memrchr() and wmemrchr() as possible candidates
for standardization, but the Austin Group would rather standardize
only memrchr() (can anyone even think of software where a proposed
wmemrchr() would be useful?)

- https://austingroupbugs.net/view.php?id=1635
Questions on whether iconv() needs to be able to distinguish between
errors on the input (an invalid multibyte sequence) from errors on the
output (no character available to properly represent the
transliteration of the recognized input).

- https://austingroupbugs.net/view.php?id=1824
Behavior of cp on directories vs. symlinks. Some of this may stem from
the fact that Linux has intentionally decided to not follow a strict
reading of POSIX on a number of interfaces: POSIX claims that if
"olddir" is a directory, and "dangling" is a symlink with contents
"newdir" but there is no directory entry named "newdir" yet, then
rename("olddir", "dangling/") should succeed with "dangling" still a
symlink and with "newdir" now existing as the directory inode that
used to be named "olddir"; but on Linux, it fails with ENOTDIR.
(There are several syscalls where Linux thinks that chasing through a
dangling symlink followed by a trailing slash to serve as a directory
name is non-ideal, and intentionally differs from a strict POSIX
reading).

Is it worth a concerted effort to try and modify POSIX to acknowledge
that there are two schools of thoughts on how a dangling symlink with
trailing slash should be interpreted (with most traditional Unix
resolving through the symlink, but Linux rejecting it up-front)?  And
if not, do we need to change the behavior of GNU cp and friends and/or
relax the wording of command line tools like cp to better describe how
they fare in the face of the divergent behavior in underlying
syscalls?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org