From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26035 invoked by alias); 27 Sep 2005 18:33:36 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3092 invoked by uid 22791); 27 Sep 2005 18:15:09 -0000 Received: from dumbledore.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.11) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 27 Sep 2005 18:15:09 +0000 Received: (qmail 1506 invoked from network); 27 Sep 2005 18:15:07 -0000 Received: from unknown (HELO ?192.168.0.4?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Sep 2005 18:15:07 -0000 Message-ID: <43398C31.5000303@codesourcery.com> Date: Tue, 27 Sep 2005 18:33:00 -0000 From: Mark Mitchell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: DJ Delorie CC: gdb@sources.redhat.com, gdb-patches@sources.redhat.com, ian@airs.com Subject: Re: PATCH: Do not call xmalloc_failed in expandargv References: <200509271451.j8REpKeg029702@sethra.codesourcery.com> <200509271540.j8RFeBbf016490@greed.delorie.com> <43396939.4030602@codesourcery.com> <200509271623.j8RGNDDA017974@greed.delorie.com> In-Reply-To: <200509271623.j8RGNDDA017974@greed.delorie.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00218.txt.bz2 DJ Delorie wrote: >>xmalloc is in libiberty, and it calls xmalloc_failed when it fails, >>which itself calls xexit. That's the source of the idiom; I was >>just trying to be consistent. > > > I don't feel strongly about it. I bring it up only to cover all > possibilities. I guess if you run out of memory in the first > allocation after main starts, you're screwed anyway. Er... don't > expect fputs() to work if you're out of memory at that point; it won't > be able to allocate stdio buffers. write(2,...) would be safer, if > less portable. xmalloc_failed uses fprintf, which is surely at least as likely as fprintf to allocate memory. And, write(2, ...) is also considered unsafe; we had this argument in the context of libstdc++ a while back. (Some applications close file descriptor 2, and then open some other file, which happens to be assigned descriptor 2.) You can avoid this if you mandate that all applications using libiberty make sure that file descriptor 2 is stderr. Anyhow, it seems weird to change expandargv if we don't change xmalloc_failed. > Hmmm... dupargv calls malloc(), not xmalloc(). expandargv calls > xmalloc(), but that's the only call to xmalloc in that file. I wonder > if we're looking at the wrong idiom for this file? In my original patch, expandargv returned an error code, or, actually, the name of the file it couldn't read. IIRC, you asked me to remove that, so that callers would require as few changes as possible. In practice, we're typically going to call expandargv() exactly once, at the top of main. Bombing out fatally doesn't seem bad to me in this case; applications aren't going to be very likely to recover. It seems like we're worrying about a very low-probability situation. If we find an application that really wants to recover from "@foo" being too big, we can always change expandargv to ignore the "@foo" option as you suggested, or to return -1, or some such. Of course, if you do want me to make this change, I will. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304