Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759636AbYJJNDY (ORCPT ); Fri, 10 Oct 2008 09:03:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758971AbYJJNDE (ORCPT ); Fri, 10 Oct 2008 09:03:04 -0400 Received: from ns.firmix.at ([62.141.48.66]:5912 "EHLO ns.firmix.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758938AbYJJNDC (ORCPT ); Fri, 10 Oct 2008 09:03:02 -0400 Subject: Re: dup2() vs dup3() inconsistency when From: Bernd Petrovitsch To: mtk.manpages@gmail.com Cc: "H. Peter Anvin" , Ulrich Drepper , Al Viro , LKML In-Reply-To: References: <48EE3D84.6000003@zytor.com> <48EE6A2B.8030005@redhat.com> <48EE6CD6.10007@zytor.com> <48EE6F22.5070306@redhat.com> <48EE703C.7070901@zytor.com> <1223640571.8832.60.camel@spike.firmix.at> Content-Type: text/plain Organization: Firmix Software GmbH Date: Fri, 10 Oct 2008 15:02:44 +0200 Message-Id: <1223643764.8832.67.camel@spike.firmix.at> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.2) Content-Transfer-Encoding: 7bit X-Firmix-Scanned-By: MIMEDefang 2.56 on ns.firmix.at X-Firmix-Spam-Score: -2.336 () AWL,BAYES_00,FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS X-Firmix-Spam-Status: No, hits=-2.336 required=5 X-Spam-Score: -2.336 () AWL,BAYES_00,FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS X-Firmix-Envelope-From: X-Firmix-Envelope-To: Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1774 Lines: 47 On Fri, 2008-10-10 at 14:15 +0200, Michael Kerrisk wrote: > On Fri, Oct 10, 2008 at 2:09 PM, Bernd Petrovitsch 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()". > 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). So I would include it in dup3() too. But a sane, clear and consistent definition and handling of flags are more important the auto-close() feature. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/