Bug 216876 - prototype for execveat() in the documentation appears wrong
Summary: prototype for execveat() in the documentation appears wrong
Status: RESOLVED DOCUMENTED
Alias: None
Product: Documentation
Classification: Unclassified
Component: man-pages (show other bugs)
Hardware: All Linux
: P1 low
Assignee: documentation_man-pages@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-01-02 03:47 UTC by Mark Galeck
Modified: 2023-05-19 13:23 UTC (History)
0 users

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Mark Galeck 2023-01-02 03:47:47 UTC
prototype for execveat() in the documentation is:

int execveat(int dirfd, const char *pathname,
                    const char *const argv[], const char *const envp[],
                    int flags);


This appears to be inconsistent with similar functions, other documentation, and my sources (latest Ubuntu distribution). 


I think two of the "const" should be dropped so that we should have:

int execveat(int dirfd, const char *pathname,
                    char *const argv[], char *const envp[],
                    int flags);
Comment 1 Florian Weimer 2023-01-02 15:26:40 UTC
* 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

Note You need to log in before you can comment on or make changes to this bug.