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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 15143 invoked from network); 27 Feb 2021 17:43:03 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Feb 2021 17:43:03 -0000 Received: (qmail 13869 invoked by uid 550); 27 Feb 2021 17:43:00 -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 13848 invoked from network); 27 Feb 2021 17:42:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vr9JybMniRP071hkr7dBtA9i8IOJwwRgEp62Kidzn6A=; b=lzLKav+3HasnUo8MJgs3Q8RtjZOtHWler1zKXcGv5NN9TMOW5DAQP8vZvht4wRnnvc C2/IjWLsx7aWyIgxhxvWt6ll92DzEJp2kWHtMJXAi8MkrIxCqVwBqQ8+QNQUt/V5glA4 HeZDffFbGzE507Zm6lnHySY5OtRjaWXZACEtZcbnEA4uob6Bo1jkhdjcusmmQT7jagf+ DSnZw1hjlR6HX6HRTCGi0dMypHgkyJANpwvjIUr7d12tKuXwLquUhyP37/uZJwinq7QJ 6VNd3e9wRyn3JSYM3xxjSxs/BKImHUyq3EcBNdx6LYvhI/o/sKtmfqZSBFIqD8N/cMdd 0WFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vr9JybMniRP071hkr7dBtA9i8IOJwwRgEp62Kidzn6A=; b=nOSUf1SF2MuG0N1BscFKWu2tSQRvga+Ckex/6U39iT3n6627VbfalzWCfHA1ArKHrM kMLO29Qjr3uL45bf4zOuAvUyR5A9MhjmhXCIr8TrDKCGmOX2prC78tptydAq+VSuEeMF O7zOJQJzEkSjc2geCH1m0ft4hMRmL/SZHbBdUIff34MTCbSyDcphbgDG8pAU1BMij6sa CsgycNylevWcuXIAFOz8ctsfA1zS3D+VMA57Byb4hG6AjrOPmZ72FssCfDShcNkyLvwF LnMUzgpDDUpnZYslA+lnh3lrVECIJwnKmFpeEWyHdpTtNsVcCK8zSs94ZnqntL5LHPhL EKgQ== X-Gm-Message-State: AOAM533ysBSTqdCrvEkdNplibZl1wZ6/UAPJByXjdnVULbJkuCYGjtRC hOhKwtma4mq/TFFTrF1MMnFErtlC6yiac2zLlvVsbuD+S7E= X-Google-Smtp-Source: ABdhPJw3od3uXl985bHHb1/wMi7y6CflyAzcwYXjTZsfDlRgy86cJtlENRWzZKygMsPIU79EOUfRf4wsxnNSz3/ElEM= X-Received: by 2002:a05:620a:12ae:: with SMTP id x14mr8025842qki.25.1614447767887; Sat, 27 Feb 2021 09:42:47 -0800 (PST) MIME-Version: 1.0 References: <77f18b20-f3fc-7b07-42e8-8fa013e52ec9@gmail.com> <20210226180040.GC32655@brightrain.aerifal.cx> <20210227173504.GD32655@brightrain.aerifal.cx> In-Reply-To: <20210227173504.GD32655@brightrain.aerifal.cx> From: Khem Raj Date: Sat, 27 Feb 2021 09:42:21 -0800 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com, Dominic Chen Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] fdopen() doesn't check for valid fd On Sat, Feb 27, 2021 at 9:35 AM Rich Felker wrote: > > 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. > Perhaps that better since it will cover a broad range of issue. We might sight this as an example there perhaps and suggest to watch for such usecases. > Rich