Re: [musl] fdopen() doesn't check for valid fd

[Khem Raj <raj.khem@gmail.com>]

On Sat, Feb 27, 2021 at 9:35 AM Rich Felker <dalias@libc.org> 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 <dalias@libc.org> 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