From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-20958-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
	RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no
	version=3.4.4
Received: from second.openwall.net (second.openwall.net [193.110.157.125])
	by inbox.vuxu.org (Postfix) with SMTP id 9757E27DBD
	for <ml@inbox.vuxu.org>; Fri, 24 May 2024 19:03:40 +0200 (CEST)
Received: (qmail 9747 invoked by uid 550); 24 May 2024 17:03:36 -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 9713 invoked from network); 24 May 2024 17:03:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=espindo.la; s=MBO0001;
	t=1716570205;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type;
	bh=/WFnlVyfn/L49Af1goZvGTvafT1NUGPllhunWv3/BMM=;
	b=wqdZUbxQQtJ9M7FOfXFD6//FN1DUWUp90j9ugXZwwTS7hlAWdAn1oYZvksFdM8E7EdQTe9
	S9tISSQ7Y7p7gkfImlOJVyAxIF53lk40mwGjvKWo/zGUZlXA0WtMbt5Xgfd814Pp5Zjqft
	k+QiAUpylsm+zcgAtYnBRQH989Xowuf+/XxCU1RZHgz3DHRfwrE4QdXChm0fybM4L9XmTJ
	FaRNT8gvP7HfTpC+e7SP38+FyY3eLR8DUN49w3k1w22SRo2kR2FjLXM9pb+eZ9qbO2afSv
	wQRX078i7BQDvz/cqQF2bjei3T5hKPnjbw8NhhNtBp0z/DJVXSEtL9D/3Njlew==
From: =?utf-8?Q?Rafael_=C3=81vila_de_Esp=C3=ADndola?= <rafael@espindo.la>
To: musl@lists.openwall.com
Date: Fri, 24 May 2024 17:03:59 +0000
Message-ID: <87v833cfb4.fsf@espindo.la>
MIME-Version: 1.0
Content-Type: text/plain
Subject: [musl] ioctl signature

The signature of ioctl in musl is

int ioctl (int, int, ...);

In glibc it is

int ioctl(int fd, unsigned long request, ...);

The requests are always 32 bits, and the most significant bit is used to
indicated that this ioctl is a read operation. This means that some
constants are negative numbers if using an int. I have noticed this
because rust's interface to libc matches the system libc implementation,
and in alpine I got an error for a literal out of range for
0xc0104801. I don't know if a C compiler would produce a warning, but
that seems somewhat reasonable.

Should the declaration be changed to use an unsigned request?:

int ioctl (int, unsigned int, ...);

Thanks,
Rafael