Re: dup2 on mingw

[Eric Blake]

Eric Blake <ebb9 <at> byu.net> writes:

> > Yes, that's definitely a portability pitfall that warrants a wrapper module.
> 
> And in writing the testcase, I learned that cygwin 1.5 also has a bug, in
> that dup2(1,1) returns 0 (but at least cygwin's dup2(1,2) returns 2).
> Although you seldom see code using dup2 as a no-op for an fd onto itself,
> it provides a great way to non-destructively check whether an fd is open
> without having to use fcntl or _get_osfhandle (and so I did just that in
> test-pipe.c).

Well, it would be nice if doing that didn't hang mingw.  It looks like 
Microsoft has a bug, because using dup2(fd,fd) when fd is closed appears to 
deadlock the process.

I also botched the interaction between fchdir and dup2 (they can't both define 
rpl_dup2).

I'm working on a followup patch for both of these issues.

-- 
Eric Blake