https://bugzilla.kernel.org/show_bug.cgi?id=216876 --- Comment #1 from Florian Weimer (fweimer@xxxxxxxxxx) --- * Alejandro Colomar via Libc-alpha: > It seems that glibc added a wrapper recently, and I didn't check that > the prototype changed: > > alx@asus5775:~/src/gnu/glibc$ grepc execveat > ./posix/unistd.h:300: > extern int execveat (int __fd, const char *__path, char *const __argv[], > char *const __envp[], int __flags) > __THROW __nonnull ((2, 3)); > > > ./sysdeps/unix/sysv/linux/execveat.c:25: > int > execveat (int dirfd, const char *path, char *const argv[], char *const > envp[], > int flags) > { > /* Avoid implicit array coercion in syscall macros. */ > return INLINE_SYSCALL_CALL (execveat, dirfd, path, &argv[0], &envp[0], > flags); > } > > > I CCd glibc so that they can comment. POSIX uses these types for fexecve and execve, and it seemed right to be consistent with that. There are several more manual pages which do not specify the correct prototype: open, openat, prctl. I have received compiler bug reports when people used function pointers modeled after the declarations of open and prctl in the manual pages because of the ABI mismatch with the glibc implementations. The execveat difference is harmless in comparison. Thanks, Florian -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.