named pipe is borken and proposed fix

[Laurent Bercot]

> The problem is that FIFO is a special file type, and the conventional EOF is useless, and should not be set.
> My proposed fix is to avoid setting __FLAG_EOF for stream associated with FIFO after sender was closed.

 Good findings, and good call.

 It's worth noting that the Linux kernel exhibits the same
behaviour with FIFOs:
 - EOF will be sent when the last writer closes
 - subsequent read()s by the same reader will always return EOF
 - that includes select() and poll(): after the last writer closes,
select() and poll() will always return readability/EOF on the reading
end of a FIFO, until the reader closes and opens it again.

 Some other operating systems behave the same way; others don't.
The standard does not specify what is right; it allows a lot of
implementation-defined behaviour with FIFOs.
 The generally accepted, portable way to handle sequential reads
on a FIFO is for the reader to also open the writing end of the
FIFO (and do nothing with it) for as long as it wants to read. The
reader is then certain to never get EOF, which only happens when the
last writer closes.

 FIFOs are tricky beasts. They should be used with extreme caution by
programmers; leaving low-level FIFO handling to stdio is a good way to
shoot yourself in the foot.

 Which does not mean that stdio should not try to do the right thing,
of course. I just have no idea what the right thing is, because different
situations call for different answers, and some cases will require EOF
while others won't.

 I suspect that glibc does unholy magic inside stdio for your test case
to work with glibc despite the Linux behaviour. And unfortunately, I'm
not sure it's avoidable.

-- 
 Laurent