From: Karel Zak <kzak@redhat.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: util-linux@vger.kernel.org, Florian Weimer <fweimer@redhat.com>,
Bernhard Voelker <mail@bernhard-voelker.de>
Subject: Re: [PATCH 0/4] Fix closing of standard text streams for non-glibc system
Date: Fri, 23 Aug 2019 13:52:13 +0200 [thread overview]
Message-ID: <20190823115213.wkrwcxnru2hzbz2a@10.255.255.10> (raw)
In-Reply-To: <20190820150435.mbubnjyqbgdev45q@10.255.255.10>
On Tue, Aug 20, 2019 at 05:04:39PM +0200, Karel Zak wrote:
> On Tue, Aug 20, 2019 at 03:17:42PM +0200, Patrick Steinhardt wrote:
> > That being said, if we agree on a proper fix here then I'd be
> > happy to post a v2.
>
> Go ahead.
Note that Bernhard Voelker sent me (off list, but thanks;-) another to
link the original coreutils discussion:
https://lists.gnu.org/archive/html/bug-gnulib/2019-05/msg00156.html
where is something about close() and dup(). My note:
It seems there is no ideal solution which is portable and reliable
on all platforms (kernels).
The current solution with std{out,err} close is also not elegant as the
close makes it useless with things like ASAN or another built-in debuggers,
and it's incompatible with some libc.
The question is what does it mean for util-linux. I don't think we
need 100% reliability on all platforms; the primary target is Linux,
commonly used filesystems, standard use-cases and code (=!behavior)
portability -- everything else is bonus. From this point of view
dup()+close() sounds like better than the current solution.
From my point of view all this game with the streams is just a way how
to detect some basic users' mistakes. I don't think we can detect
serious I/O errors without fsync(), and close() itself does not
guarantee anything. So, it does not make sense trying to make it
super durable, reliable and portable to all operation systems if at
the end you rely on poor close() ...
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
next prev parent reply other threads:[~2019-08-23 11:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-14 16:45 [PATCH 0/4] Fix closing of standard text streams for non-glibc system 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
2019-08-23 11:52 ` Karel Zak [this message]
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=20190823115213.wkrwcxnru2hzbz2a@10.255.255.10 \
--to=kzak@redhat.com \
--cc=fweimer@redhat.com \
--cc=mail@bernhard-voelker.de \
--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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).