Util-Linux Archive on lore.kernel.org
 help / color / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Karel Zak <kzak@redhat.com>
Cc: Patrick Steinhardt <ps@pks.im>, util-linux@vger.kernel.org
Subject: Re: [PATCH 0/4] Fix closing of standard text streams for non-glibc system
Date: Tue, 20 Aug 2019 17:11:55 +0200
Message-ID: <87tvabna6c.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20190820150435.mbubnjyqbgdev45q@10.255.255.10> (Karel Zak's message of "Tue, 20 Aug 2019 17:04:35 +0200")

* Karel Zak:

> 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 :-)

Even in that case, dup3 would still be relevant to multi-threaded
programs.  I don't know about the context, it may not be relevant to
util-linux.

Thanks,
Florian

  reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14 16:45 Patrick Steinhardt
2019-08-14 16:45 ` [PATCH 1/4] term-utils/ttymsg: fix missing header for ARRAY_SIZE macro Patrick Steinhardt
2019-08-14 16:45 ` [PATCH 2/4] login-utils/islocal: fix missing header for err macro Patrick Steinhardt
2019-08-14 16:45 ` [PATCH 3/4] lib/closestream: move implementation into its own compilation unit Patrick Steinhardt
2019-08-14 16:45 ` [PATCH 4/4] lib/closestream: fix assignment to read-only standard streams Patrick Steinhardt
2019-08-19 13:36 ` [PATCH 0/4] Fix closing of standard text streams for non-glibc system Karel Zak
2019-08-20 13:17   ` Patrick Steinhardt
2019-08-20 15:04     ` Karel Zak
2019-08-20 15:11       ` Florian Weimer [this message]
2019-08-23 11:52       ` Karel Zak
2019-08-22  9:40 ` [PATCH v2] include/closestream: fix assignment to read-only standard streams Patrick Steinhardt
2019-08-23 12:00   ` Karel Zak
2019-09-02 10:01   ` Karel Zak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tvabna6c.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=kzak@redhat.com \
    --cc=ps@pks.im \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Util-Linux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/util-linux/0 util-linux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 util-linux util-linux/ https://lore.kernel.org/util-linux \
		util-linux@vger.kernel.org
	public-inbox-index util-linux

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.util-linux


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git