From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6834 invoked by alias); 6 Dec 2008 16:54:09 -0000 Received: (qmail 6826 invoked by uid 22791); 6 Dec 2008 16:54:08 -0000 X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 06 Dec 2008 16:53:33 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1L90Op-0002JC-Ou; Sat, 06 Dec 2008 11:52:59 -0500 From: Eli Zaretskii To: Tom Tromey CC: gdb-patches@sourceware.org In-reply-to: (message from Tom Tromey on Sat, 06 Dec 2008 08:58:03 -0700) Subject: Re: RFA: close-on-exec internal file descriptors Reply-to: Eli Zaretskii References: Message-Id: Date: Sat, 06 Dec 2008 16:54:00 -0000 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/msg00115.txt.bz2 > Cc: gdb-patches@sourceware.org > From: Tom Tromey > Reply-To: Tom Tromey > Date: Sat, 06 Dec 2008 08:58:03 -0700 > > Eli> Relying on glibc is OK for GNU/Linux, but you seem to be modifying > Eli> files that have no relation to the Linux native builds. Does that > Eli> mean the non-glibc builds that don't have the support you are relying > Eli> on will still leak descriptors? > > No. In each case, if O_CLOEXEC is not available, we fall back to the > fcntl-based method. That is what the calls to "close_on_exec" do in > the patch. It seemed to me that the patch assumes too much about the various #define's -- which is OK if you are targeting glibc, but may need refinement for other libc's. But perhaps I missed something; I will take another look. > >> + char new_mode[20]; > >> + strcpy (new_mode, mode); > >> + strcat (new_mode, "e"); > >> + return fopen (path, new_mode); > > Eli> Can we do something more safe than this arbitrary [20] limitation? > > I don't think there is any point, because the mode argument to fopen > is never longer than 4 characters or so. However, if you really want > this, I will change it to a malloc. I just don't like relying on "is never longer than N" assumptions, and GNU coding standards frown on arbitrarily dimensioned arrays, so...