[Top][All Lists]

[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

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

* 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
  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]