> Those appear to be specifically about the stdio streams, not the file 
> descriptors.  I think a stream that returns an EBADF error for all 
> operations would be perfectly valid for the purposes of those 
> requirements.
Right, ISO C has no concept of file descriptors at all, and the paragraph I
referenced in POSIX is (almost) a copy of the one in C, so yes, it's most
likely talking about the std{in,out,err} objects.

> > This specific part of the quote would seem to imply that standard input, output
> > and error must be opened for reading and writing respectively?
> 
> Yes - that is, what the implementation does if standard input is not open 
> for reading, or standard output and error are not open for writing, is not 
> specified.
The "may" in the sentence indeed does leave it unspecified, but it seems hinted
that these file descriptors should be open for startup. It also says that this
should only happen if a special file descriptors stays closed after exec, so
there is no need to worry about the case where the parent makes fd 0 write only.
And considering the hint, and that the edge case of stdin being closed seems to
have been missed even by the autotools developers (I noticed this when running
autoconf-1.64s ./configure from an automation tool that closed fd 0), which I'd
expect to have noticed this problem in *some* system, I'd say it's probably a
change that can't hurt, but could help, since it seems to have been assumed by
everyone forever.

Also, the sentence talked about here seems to be pretty explicit: either the
implementation opens fd 0 for reading and fds 1 and 2 for writing, or it is
non-conforming.
This also means that the changes Paul was concerned about (due to which
initially I revisioned the patch), actually, should be in the patch also.
Of course, that is under the assumption that this doesn't only apply when the
implementation decides to do something in this case.

-- 
Arsen Arsenović