[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug-diffutils] bug#33965: bug#33965: handling of closed file descriptor
From: |
Bruno Haible |
Subject: |
[bug-diffutils] bug#33965: bug#33965: handling of closed file descriptors |
Date: |
Sat, 05 Jan 2019 00:30:39 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-141-generic; KDE/5.18.0; x86_64; ; ) |
Sorry, Paul, but I have to vehemently disagree here. You are mixing
two different questions:
(A) What is the best behaviour for a kernel?
(B) What is the best behaviour for a program?
About (A):
> We should encourage platforms like HP-UX that try to work around the
> trouble
The question is: Is it better for a kernel to be minimalist, hence
exec() does nothing special with the file descriptors? Or is it better
for a kernel to avoid pitfalls for programs, by protecting the first
3 file descriptors?
It is similar to the question: In the case of a signal delivery, should
a read() or write() system call return with a partial result or EINTR, or
should the kernel protect the programs from this knowledge and programming
overhead? This question was extensively discussed under the title
"worse is better", see
https://www.jwz.org/doc/worse-is-better.html
https://en.wikipedia.org/wiki/Worse_is_better
I have no personal opinion on this question.
About (B):
> I'd rather think of this as a bug in the test case, not a bug in 'diff'.
Here I disagree.
* The majority of the uses of 'diff' and coreutils is through shell scripts.
* <&- and >&- are POSIX-standardized syntaxes in shell scripts for a long
time.
* It is a goal to make the same shell script work the same way on different
platforms. The user gains nothing if you tell them "your shell script
works differently on Linux than on HP-UX because the kernel behaves
slightly differently".
* Therefore the gnulib modules
dirent-safer
fcntl-safer
fopen-safer
freopen-safer
openat-safer
pipe2-safer
popen-safer
stdlib-safer
tmpfile-safer
unistd-safer
serve a good purpose. They make programs running on Linux and
programs running on HP-UX behave more similarly, which is a good thing.
> This is because the test case assumes more about the shell's "<&-"
> construct than what POSIX requires.
It is like saying that it would be OK for a program, when interrupted
through Ctrl-Z and restarted through 'fg', to stop processing and exit
with a message "read: Interrupted system call". That's indeed how some
programs behaved around 1992: POSIX allowed the kernel to return from a
read() system call with errno = EINTR. But users don't want this. So it
was seen as a bug in the program, and fixed.
Same here.
Bruno
- [bug-diffutils] bug#33965: handling of closed file descriptors, Bruno Haible, 2019/01/03
- [bug-diffutils] bug#33965: handling of closed file descriptors, Bruno Haible, 2019/01/03
- [bug-diffutils] bug#33965: bug#33965: handling of closed file descriptors, Jim Meyering, 2019/01/04
- [bug-diffutils] bug#33965: bug#33965: bug#33965: handling of closed file descriptors, Paul Eggert, 2019/01/04
- [bug-diffutils] bug#33965: bug#33965: handling of closed file descriptors,
Bruno Haible <=
- [bug-diffutils] bug#33965: bug#33965: handling of closed file descriptors, Paul Eggert, 2019/01/04
- [bug-diffutils] bug#33965: bug#33965: handling of closed file descriptors, Bruno Haible, 2019/01/05
- [bug-diffutils] bug#33965: handling of closed file descriptors, Bruno Haible, 2019/01/05
- [bug-diffutils] bug#33965: handling of closed file descriptors, Paul Eggert, 2019/01/05
- Message not available
- [bug-diffutils] bug#33965: handling of closed file descriptors, Paul Eggert, 2019/01/06