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 14344 invoked from network); 27 Feb 2021 17:35:20 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Feb 2021 17:35:20 -0000 Received: (qmail 7880 invoked by uid 550); 27 Feb 2021 17:35:18 -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 7859 invoked from network); 27 Feb 2021 17:35:17 -0000 Date: Sat, 27 Feb 2021 12:35:04 -0500 From: Rich Felker To: Khem Raj Cc: musl@lists.openwall.com, Dominic Chen Message-ID: <20210227173504.GD32655@brightrain.aerifal.cx> References: <77f18b20-f3fc-7b07-42e8-8fa013e52ec9@gmail.com> <20210226180040.GC32655@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] fdopen() doesn't check for valid fd On Sat, Feb 27, 2021 at 09:13:17AM -0800, Khem Raj wrote: > On Fri, Feb 26, 2021 at 10:01 AM Rich Felker wrote: > > > > 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. > > > > perhaps we should add it to differences with glibc document [1] > > > Rich > > [1] https://wiki.musl-libc.org/functional-differences-from-glibc.html I'm not fundmanetally opposed to that, but it should probably be a more general statement about "may fail" and UB; otherwise we'd end up documenting a very large number of little details like this one. Rich