All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx.manpages@gmail.com>
To: bugzilla-daemon@kernel.org,
	GNU C Library <libc-alpha@sourceware.org>,
	markgaleck@gmail.com, linux-man <linux-man@vger.kernel.org>
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Subject: Re: [Bug 216876] New: prototype for execveat() in the documentation appears wrong
Date: Mon, 2 Jan 2023 16:02:05 +0100	[thread overview]
Message-ID: <1fed37b4-0bf6-0e20-56ff-2e006928989c@gmail.com> (raw)
In-Reply-To: <bug-216876-216477@https.bugzilla.kernel.org/>


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

Hi,

On 1/2/23 04:47, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=216876
> 
>              Bug ID: 216876
>             Summary: prototype for execveat() in the documentation appears
>                      wrong
>             Product: Documentation
>             Version: unspecified
>            Hardware: All
>                  OS: Linux
>              Status: NEW
>            Severity: low
>            Priority: P1
>           Component: man-pages
>            Assignee: documentation_man-pages@kernel-bugs.osdl.org
>            Reporter: markgaleck@gmail.com
>          Regression: No
> 
> 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);

Thanks for the report!

This was introduced in commit 71a25d4c79b1ccf538f6b813c834bbc4197f6370
"execveat.2: Fix prototype".

The reason is that the kernel uses the const:

alx@asus5775:~/src/linux/linux$ grepc execveat
./include/linux/compat.h:851:
asmlinkage long compat_sys_execveat(int dfd, const char __user *filename,
		     const compat_uptr_t __user *argv,
		     const compat_uptr_t __user *envp, int flags);


./include/linux/syscalls.h:1011:
asmlinkage long sys_execveat(int dfd, const char __user *filename,
			const char __user *const __user *argv,
			const char __user *const __user *envp, int flags);


./fs/exec.c:2096:
SYSCALL_DEFINE5(execveat,
		int, fd, const char __user *, filename,
		const char __user *const __user *, argv,
		const char __user *const __user *, envp,
		int, flags)
{
	return do_execveat(fd,
			   getname_uflags(filename, flags),
			   argv, envp, flags);
}


./fs/exec.c:2115:
COMPAT_SYSCALL_DEFINE5(execveat, int, fd,
		       const char __user *, filename,
		       const compat_uptr_t __user *, argv,
		       const compat_uptr_t __user *, envp,
		       int,  flags)
{
	return compat_do_execveat(fd,
				  getname_uflags(filename, flags),
				  argv, envp, flags);
}


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.

Cheers,

Alex

P.S.:  There's some problem in bugzilla that it's not receiving my replies, so I 
CCed everyone involved so we can keep the discussion in the mailing list.

P.S.2:  Ping, Konstantin, please check that.

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

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

       reply	other threads:[~2023-01-02 15:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-216876-216477@https.bugzilla.kernel.org/>
2023-01-02 15:02 ` Alejandro Colomar [this message]
2023-01-02 15:26   ` [Bug 216876] New: prototype for execveat() in the documentation appears wrong Florian Weimer
2023-01-02 16:12     ` Alejandro Colomar
2023-01-02  3:47 bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1fed37b4-0bf6-0e20-56ff-2e006928989c@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=bugzilla-daemon@kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=markgaleck@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.