Messages in this thread | | | Date | Fri, 10 Oct 2008 15:15:14 +0200 | From | "Michael Kerrisk" <> | Subject | Re: dup2() vs dup3() inconsistency when |
| |
On Fri, Oct 10, 2008 at 3:02 PM, Bernd Petrovitsch <bernd@firmix.at> wrote: > On Fri, 2008-10-10 at 14:15 +0200, Michael Kerrisk wrote: >> On Fri, Oct 10, 2008 at 2:09 PM, Bernd Petrovitsch <bernd@firmix.at> wrote: >> > On Fri, 2008-10-10 at 07:04 +0200, Michael Kerrisk wrote: >> > [....] >> >> Well, as long as we are fixing the dup3() interface in the way that Al >> >> and Ulrich have suggested, what about another fix: >> >> >> >> give an error if newfd is already open, thus forcing the user to do an >> >> explicit close >> >> >> >> ? >> >> >> >> This silent close in dup2() is an implementation blemish. Why not eliminate it? >> > >> > Apart from the usual "do not break almost all existing apps" killer >> > reason: The alternative is that people will simply add a "close(newfd)" >> > everytime before "dup2(oldfd,newfd)" since close() is harmless on a >> > non-open fd. >> >> Bernd, >> >> I think you've missed the point. The idea is not to change to dup2(), > > That may well be. So the "eliminate it" apparently doesn't mean > "eliminate it in dup2()".
Right.
>> but to eliminate the blemish in its design in the new dup3() (since we >> have alrady eliminated one other blemish). > > FWIW I consider the automatic close() in dup2() a feature (if only that > it avoids an additional system call).
Exploiting this "feature" can hide real errors that would be detected if one does an explicit close(). (See the dup2 man page.)
Cheers,
Michael
| |