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

[Paul Eggert]

On 1/4/19 3:30 PM, Bruno Haible wrote:
> > 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".

I don't see the analogy at all. Currently diffutils has a test shell 
script that is not portable POSIX code. Although we've worked around the 
problem with HP-UX by hacking on 'diff' itself, there are plausible 
POSIX platforms where our current hack will not work. It's not 
unreasonable to expect that test scripts should limit themselves to 
POSIX features so that they are as portable as reasonably possible.

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

If by "users" you mean "programs that make system calls", then many 
users *do* want that. Certainly Emacs does, and I imagine many other 
programs do too. If you meant something else by "users" then I'm not 
sure I'm following the analogy.

For the stdin-is-closed situation, the users and developers of many (I 
would say most) applications do not want 'open' to hijack stdin. 
Although the HP-UX solution to this problem may not be best, it's better 
than the traditional behavior as it is a simple change to the kernel 
that fixes the issue for all applications, as opposed to the 
more-complicated dances we do in openat-safer and friends.

After thinking about this a bit more, the message that I'm getting from 
all this is that we should change diffutils to no longer rely on the 
"feature" that stdin is closed, and remove the test cases that attempt 
to test for this "feature". The feature is not portable to POSIX 
platforms. Besides, I doubt whether anybody is using the feature anyway. 
I put the feature in many years ago, so I can take the blame for 
introducing the misguided feature and the responsibility for taking it out.