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
