From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 975181C6F70 for ; Thu, 23 Jan 2025 13:51:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=163.172.96.212 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737640313; cv=none; b=melVZYfL6KlBoKfInIAYyF7DMA3KJQ7px2vzt3yAI/l5JEPGdBrcIFVkjgGx1wxnvsOkJBel+mEW8eb6yAetaLyhNgY5B6q9a0U5hi+XDKrDPQ+ArN56py+Y+itpoWxmvbsPLKFJ0m4p5cNBg9TiGJIThmwm7Xq8bXVz/gM6PI8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737640313; c=relaxed/simple; bh=FbjZhR6QrivPyRW+FQam/ByTlLk6Kdc7VFNYgD/7jFw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r7JC/zl0xGtXEDy76NQJTwHvvPySZgAYbvV98iuiLStAwUaYuUldhjzzErIHH9J2CiknZgfqHZbDP1AE8ijawXbNN3mCqbb8kp7YB8rORFJ2NWNk1IQ69uLGJNpre0/ZIUDyIy+HtNuSi41zY+fZMzw+X5tJm4LeKK9oHPJdKAI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; arc=none smtp.client-ip=163.172.96.212 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 50NDplgH010136; Thu, 23 Jan 2025 14:51:47 +0100 Date: Thu, 23 Jan 2025 14:51:47 +0100 From: Willy Tarreau To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] tools/nolibc: align signature of ioctl() with POSIX Message-ID: <20250123135147.GE8580@1wt.eu> References: <20250123-nolibc-ioctl-v1-1-93f8bca99de5@weissschuh.net> <20250123131625.GD8580@1wt.eu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) On Thu, Jan 23, 2025 at 02:24:13PM +0100, Thomas Weißschuh wrote: > On 2025-01-23 14:16:25+0100, Willy Tarreau wrote: > > Hi Thomas, > > > > On Thu, Jan 23, 2025 at 02:04:29PM +0100, Thomas Weißschuh wrote: > > > POSIX defines the signature of ioctl() as follows, > > > to allow passing a pointer or integer without casting: > > > int ioctl(int fildes, int request, ... /* arg */); > > > > > > Nolibc ioctl() expects a pointer, forcing the user to manually cast. > > > Using va_arg to make the signature more flexible would work but seems to > > > prevent inlining of the function. Instead use a macro. "fd" and "req" > > > will still be typechecked through sys_ioctl(). > > > > > > Signed-off-by: Thomas Weißschuh > > > --- > > > tools/include/nolibc/sys.h | 8 ++------ > > > 1 file changed, 2 insertions(+), 6 deletions(-) > > > > > > diff --git a/tools/include/nolibc/sys.h b/tools/include/nolibc/sys.h > > > index d4a5c2399a66b200ebf7ab249569cce2285481a5..5cb2c66cc8cccc4d4a1126acfd0b30a6efc886c3 100644 > > > --- a/tools/include/nolibc/sys.h > > > +++ b/tools/include/nolibc/sys.h > > > @@ -532,7 +532,7 @@ uid_t getuid(void) > > > > > > > > > /* > > > - * int ioctl(int fd, unsigned long req, void *value); > > > + * int ioctl(int fd, unsigned long req, ... value); > > > */ > > > > > > static __attribute__((unused)) > > > @@ -541,11 +541,7 @@ int sys_ioctl(int fd, unsigned long req, void *value) > > > return my_syscall3(__NR_ioctl, fd, req, value); > > > } > > > > > > -static __attribute__((unused)) > > > -int ioctl(int fd, unsigned long req, void *value) > > > -{ > > > - return __sysret(sys_ioctl(fd, req, value)); > > > -} > > > +#define ioctl(fd, req, value) __sysret(sys_ioctl(fd, req, (void *)(value))) > > > > You risk to get a warning about casting a pointer from an integer of > > a different size if you pass an int there. I think should should perform > > a double cast instead: > > > > #define ioctl(fd, req, value) __sysret(sys_ioctl(fd, req, (void *)(uintptr_t)(value))) > > > > That way any int should cast fine, and pointers should as well. > > I don't think this should ever happen. A warning there is actually > useful. The POSIX signature forces users to pass something that is > compatible with (void *), otherwise the vararg handling would be > invalid. I'm a bit confused because while my man page says: The third argument is an untyped pointer to memory. what I'm finding in POSIX is: The type of arg depends upon the particular control request, but it shall be either an integer or a pointer to a device-specific data structure. So I'm not seeing anything insisting on the int being the size of a pointer. Even the FreeBSD man explicitly mentions char *, caddr_t or int. Thus I do think that int is expressly permitted and might exist. I mean, I don't care much, but if we try to fix something that requires a cast, to end up with users having to write "(long)i" in their code, we won't have made much progress :-/ Willy