From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-15236-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,
	RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2
Received: from mother.openwall.net (mother.openwall.net [195.42.179.200])
	by inbox.vuxu.org (OpenSMTPD) with SMTP id 569a5bdf
	for <ml@inbox.vuxu.org>;
	Mon, 20 Jan 2020 12:57:46 +0000 (UTC)
Received: (qmail 8080 invoked by uid 550); 20 Jan 2020 12:57:44 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 8062 invoked from network); 20 Jan 2020 12:57:44 -0000
Date: Mon, 20 Jan 2020 15:57:33 +0300 (MSK)
From: Alexander Monakov <amonakov@ispras.ru>
To: musl@lists.openwall.com
cc: Olaf Meeuwissen <paddy-hack@member.fsf.org>
In-Reply-To: <20200120120930.GO23985@port70.net>
Message-ID: <alpine.LNX.2.20.13.2001201544180.7204@monopod.intra.ispras.ru>
References: <8736cajtt1.fsf@member.fsf.org> <20200120120930.GO23985@port70.net>
User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [musl] [BUG] ioctl: overflow in implicit constant conversion

I'll reiterate points raised previously in https://www.openwall.com/lists/musl/2017/08/30/10

On Mon, 20 Jan 2020, Szabolcs Nagy wrote:

> this is a conformance bug, since posix specifies int.
> 
> one could argue that linux requires unsigned long, but
> the correct way to introduce linux specific apis is to
> give them a different name, not something that clashes
> with standard names that have specified semantics.

But _why_ does POSIX specify 'int' there? Checking on freebsd.org
man pages I see that all BSD flavours had 'unsigned long' and Linux
followed that. Did POSIX fail to document prevailing practice in
this case?


I still think the warning points to a bigger problem that with
musl the kernel receives a sign-extended value.

So I think ioctl.c should be fixed to not sign-extend the value,
_IO macros could be changed to use (int)sizeof(c) instead of
sizeof(c), and if silencing -Wsign-conversion is also desired,

#ifdef __GNUC__
#define ioctl(fd, req, ...) ioctl(fd, (int)(req), ##__VA_ARGS__)
#endif

Alexander