From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17097 invoked by alias); 6 Dec 2008 15:26:36 -0000 Received: (qmail 17089 invoked by uid 22791); 6 Dec 2008 15:26:35 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 06 Dec 2008 15:25:56 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 633AC10D5C; Sat, 6 Dec 2008 15:25:53 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 2C5EB10A56; Sat, 6 Dec 2008 15:25:53 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1L8z2W-0001Bx-53; Sat, 06 Dec 2008 10:25:52 -0500 Date: Sat, 06 Dec 2008 15:26:00 -0000 From: Daniel Jacobowitz To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: RFA: close-on-exec internal file descriptors Message-ID: <20081206152551.GA3047@caradoc.them.org> Mail-Followup-To: Tom Tromey , gdb-patches@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00109.txt.bz2 On Fri, Dec 05, 2008 at 05:38:13PM -0700, Tom Tromey wrote: > +/* Like open, but ensure that the resulting file descriptor is marked > + close-on-exec, if possible. */ > +int > +open_cloexec (const char *path, int flags, int mode) > +{ > +#ifdef O_CLOEXEC > + return open (path, flags | O_CLOEXEC, mode); If you build with headers that include O_CLOEXEC support, but the running kernel is too old, will this fail to open entirely? Or are unknown open flags ignored? Also, WDYT about separating the goal from the mechanism? With this patch, every bit of gdb knows "we close file descriptors on exec"; if it was gdb_open, it would just be "gdb-specific version of open". -- Daniel Jacobowitz CodeSourcery