> >could you please explain to me why this patch is not portable? is maybe
> >because of the explicit fd nubers? do not STDIN_FILENO, STDOUT_FILENO and
> >STDERR_FILENO costants help to sort this out?
>
> These two issues are my main concerns:
>
> 1. My man page on Linux for read() says ('count' is the number passed
> in the third argument):
>
> "If count is zero, read() returns zero and has no other results."
>
> This patch assumes that reading zero bytes from a closed file descriptor
> returns non-zero. It contradicts the man page and I am pretty confident
> that at least some operating systems will behave differently.
>
> 2. /dev/null is unix and curl compiles and runs on a whole lot of other
> systems too. It needs to be taken into account.

How about:

{
        int fd[2] = { STDIN_FILENO, STDIN_FILENO };
        while (
                fd[0] == STDIN_FILENO ||
                fd[0] == STDOUT_FILENO ||
                fd[0] == STDERR_FILENO ||
                fd[1] == STDIN_FILENO ||
                fd[1] == STDOUT_FILENO ||
                fd[1] == STDERR_FILENO
                );
                pipe(fd);

        close(fd[0]);
        close(fd[1]);
}

Might leak at most 1 fd, but seems significantly more portable and
standards-compliant.

-- 
Ian Gulliver
Penguin Hosting
"Failure is not an option; it comes bundled with your Microsoft products."