From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 95D062EC0A for ; Sun, 27 Oct 2024 23:43:56 +0100 (CET) Received: (qmail 32134 invoked by uid 550); 27 Oct 2024 22:43:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com x-ms-reactions: disallow Received: (qmail 32102 invoked from network); 27 Oct 2024 22:43:50 -0000 X-Virus-Scanned: SPAM Filter at disroot.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1730069022; bh=0ZP2SD82ambrNLs7QAT+YvLm7DAtQ1SBr0qaaZDxXqQ=; h=Date:From:To:Subject:References:In-Reply-To; b=Bei7j3GuQEP9pB+cRMci1ytPLnEj3tjPPm2PpRgQx7xyIYB9q2cKy1Xlj+qOBswVO 3cwVTP8Ys8KzkLLmb4KPBDD0u8XxOZiiDG7p+hGPoiqLBCYmCv1kFJoZU/FnLl5yYH fPw4z3TPlqtNM1BCbv1Q6oWi3zWn7CWkMfZlWMDuIzU5yUtSOT9tQtY67+CKrIEbd+ QqPV0qL0UuzLdb6LmUIz60HH0fDoU6uHMmMSJizXad8GtEby1Fqp0lVJU86oMn7ji+ n71A9SJjRZJyH52Kkvxw1iRidwZvHqne2rKT5U/4qFBaloTu1ONGGnuND/xey4TLCx av/V9Cl1GMljg== Date: Sun, 27 Oct 2024 22:43:27 +0000 From: Yao Zi To: musl@lists.openwall.com Message-ID: References: <878quc7xzy.fsf@alyssa.is> <20241025201011.GY10433@brightrain.aerifal.cx> <874j4zoob8.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [musl] Prototypes without implementations On Sat, Oct 26, 2024 at 03:22:25PM +0200, Markus Wichmann wrote: > See above. Failing with ENOSYS and no side effects is a perfectly > conforming implementation of most POSIX functions. Yes, failing with ENOSYS could be conformant. But ioperm() and iopl() aren't really a POSIX thing. Why make more pitfalls instead of easing everyone's life? For stuff like ioctl(), I do agree with that standing with POSIX is correct, but in this case we aren't getting anything valuable with a stub implementation. And I think it is not a hard work to omit both the implementation and declaration on archs without these syscalls. Thanks, Yao Zi