David Laight writes:

> On Sat, Nov 15, 2003 at 12:44:54PM +0000, David Sainty wrote:
> > 
> > Module Name:	src
> > Committed By:	dsainty
> > Date:		Sat Nov 15 12:44:54 UTC 2003
> > 
> > Modified Files:
> > 	src/bin/dd: dd.c
> > 
> > Log Message:
> > Avoid corrupting the dd(1) IO streams.  This would happen by
> > accidentally outputting to the files being manipulated by opening
> > a file in the standard IO descriptor space.  In particular, an
> > output file unlucky enough to be sitting on descriptor 2 (stderr)
> > is certain to be corrupted.
> > 
> > Addresses PR bin/8521, and passes the recently committed
> > regression test "bin/dd".
> 
> What is wrong with:
> 	new_fd = fcntl(fd, F_DUPFD, 3);
> 	close(fd);
> 	fd = newfd;

I did consider that, but it seems more error-prone.

E.g. "dd if=foo of=/dev/fd/3" would break.

Also, the fcntl(F_DUPFD)/dup2() would implicitly close the file
descriptor on 3.  Not usually a problem, but certainly new behaviour.
Who knows, someone somewhere might use closure of fd 3 as an awful way
to determine if "dd" has exited or not :)

The repeated dup()'ing will result in some extra system calls
sometimes, but it will always do the right thing...  And after all,
the common case is that the code does nothing.

Convincing enough? :)

Cheers,

Dave