Re: [PATCH 0/4] Fix closing of standard text streams for non-glibc system

From: Karel Zak <kzak@redhat.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: util-linux@vger.kernel.org, Florian Weimer <fweimer@redhat.com>
Subject: Re: [PATCH 0/4] Fix closing of standard text streams for non-glibc system
Date: Tue, 20 Aug 2019 17:04:35 +0200	[thread overview]
Message-ID: <20190820150435.mbubnjyqbgdev45q@10.255.255.10> (raw)
In-Reply-To: <20190820131742.GB50493@ncase>

On Tue, Aug 20, 2019 at 03:17:42PM +0200, Patrick Steinhardt wrote:
> On Mon, Aug 19, 2019 at 03:36:19PM +0200, Karel Zak wrote:
> > On Wed, Aug 14, 2019 at 06:45:03PM +0200, Patrick Steinhardt wrote:
> > > since commit 52aa1a661 (include/closestream: avoid close more
> > > than once, 2019-06-13), util-linux fails to build on musl libc
> > > based systems. The culprit here is that it introduced assignments
> > > to stderr and stdout, while the C89 standard explicitly notes
> > > that treating stderr and stdout as valid lvalues is not a
> > > requirement for any conforming C implementation. musl libc
> > > implemented these streams as `extern FILE *const`, and as a
> > > result assigning to these variables causes compiler errors.
> > 
> > The question is if close() for stdout and stderr is the right way to
> > go. 
> > 
> > In an ideal world it would be enough to use ferror()+fflush(),
> > unfortunately for example NFS has never reached an ideal world and it
> > requires fclose()... See
> > 
> >  https://lists.gnu.org/r/bug-gnulib/2019-04/msg00061.html
> > 
> > Florian (added to CC), also suggested to use dup3() for the
> > descriptors and then fclose() for the new handle. It sounds like a
> > pretty elegant solution how to avoid all the issues with NULL and it's
> > also robust enough if you accidentally call close_stream() more than
> > once.
> > 
> > See
> > 
> >  https://bugzilla.redhat.com/show_bug.cgi?id=1732450#c4
> > 
> > Maybe we can improve include/closestream.h to use dup3(), than it would
> > be possible keep all in the header file as inline functions. 
> > 
> > Comments?
> 
> I honestly don't get why we'd need to use dup3(2), though.
> Couldn't the same be achieved by using dup2(3P) followed by
> close(3P), instead? Especially considering that the former one
> isn't specified by POSIX, either, but the latter one is.

Well, I guess Florian has used dup3() as example and I don't think we
have to care about the flags (O_CLOEXEC)  as we close the descriptor
in the same function. The important thing is to have descriptor which we
can close to force filesystems to sync stuff :-)

> That being said, if we agree on a proper fix here then I'd be
> happy to post a v2.

Go ahead.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com