[bug-diffutils] bug#33965: bug#33965: handling of closed file descriptors

[Bruno Haible]

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