Re: [Bug 216876] New: prototype for execveat() in the documentation appears wrong

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1575 bytes --]

Hi Florian,

On 1/2/23 16:26, Florian Weimer wrote:
> * 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.

That makes sense, and is what I guessed.  I just wanted to make sure that it was 
intentional.  I've updated the page to reflect the glibc wrapper.

Cheers,

Alex

> 
> Thanks,
> Florian
> 

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]