From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15306 invoked from network); 26 Feb 2021 18:00:58 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 Feb 2021 18:00:58 -0000 Received: (qmail 15385 invoked by uid 550); 26 Feb 2021 18:00:54 -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 Received: (qmail 15361 invoked from network); 26 Feb 2021 18:00:53 -0000 Date: Fri, 26 Feb 2021 13:00:40 -0500 From: Rich Felker To: Dominic Chen Cc: musl@lists.openwall.com Message-ID: <20210226180040.GC32655@brightrain.aerifal.cx> References: <77f18b20-f3fc-7b07-42e8-8fa013e52ec9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77f18b20-f3fc-7b07-42e8-8fa013e52ec9@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] fdopen() doesn't check for valid fd On Fri, Feb 26, 2021 at 12:36:19PM -0500, Dominic Chen wrote: > I've been verifying the behavior of an application between glibc and > musl, and have noticed that the musl implementation of fdopen() > assumes that the input fd is valid, whereas glibc does not. Per > https://pubs.opengroup.org/onlinepubs/9699919799/, it seems that > fdopen() is allowed to fail with EBADF, so inside __fdopen(), the > syscalls to SYS_fcntl and SYS_ioctl should probably check for an > error, deallocate the FILE *, and return nullptr. This is specified as a "may fail" error not a "shall fail". It was discussed before (I can look up the old thread if you're interested) and there are some paths in which checking for it would be free, but others where it would not, and it would require reorganizing the function's flow in a way that's less desirable in one way or another, so it doesn't seem like a good idea for the sake of something a caller can't actually use. Rich