|
Message-ID: <20190625213525.0407b535@sf> Date: Tue, 25 Jun 2019 21:35:25 +0100 From: Sergei Trofimovich <slyfox@...too.org> To: musl@...ts.openwall.com Subject: return-value/errno for utimensat(<filefd>, NULL, NULL, 0) mismatch across musl and glibc: bug or a feature? Hi musl@ folk! The original issue popped in https://bugs.gentoo.org/549108#c22. There glibc's utimensat() wrapper handles one corner case differently from musl's wrapper. Here is the minimal reproducer: $ cat a.c #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <stddef.h> int main() { int fd = open("f", O_WRONLY|O_CREAT, 0666); return utimensat(fd, NULL, NULL, 0); } On glibc (x86_64 linux-5.2-rc5): $ gcc a.c -o a && strace -etrace=open,openat,utimensat,exit_group ./a openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "f", O_WRONLY|O_CREAT, 0666) = 3 exit_group(-1) = ? +++ exited with 255 +++ On musl (x86_64 linux-5.2-rc5): $ gcc a.c -o a && strace -etrace=open,openat,utimensat,exit_group ./a open("f", O_WRONLY|O_CREAT, 0666) = 3 utimensat(3, NULL, NULL, 0) = 0 exit_group(0) = ? The difference stems from this extra check in glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/utimensat.c;h=04b549f360b88a7e7c1e5e617158caf73299736b;hb=HEAD#l32 int utimensat (int fd, const char *file, const struct timespec tsp[2], int flags) { if (file == NULL) return INLINE_SYSCALL_ERROR_RETURN_VALUE (EINVAL); /* Avoid implicit array coercion in syscall macros. */ return INLINE_SYSCALL (utimensat, 4, fd, file, &tsp[0], flags); } while musl just calls the syscall directly: https://git.musl-libc.org/cgit/musl/tree/src/stat/utimensat.c int utimensat(int fd, const char *path, const struct timespec times[2], int flags) { int r = __syscall(SYS_utimensat, fd, path, times, flags); // ... return __syscall_ret(r); } Is this divergence expected? Or maybe it's accidental? Does it make sense to handle non-directory fds in utimensat() according to POSIX? I wonder if we should drop the unstable test or some of libc implementations actually deviates from the spec. Thank you! -- Sergei
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.