From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20426 invoked by alias); 27 Sep 2005 18:04:53 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3098 invoked by uid 22791); 27 Sep 2005 16:47:53 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 27 Sep 2005 16:47:53 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j8RGkolH013804; Tue, 27 Sep 2005 12:47:52 -0400 Received: from post-office.corp.redhat.com (post-office.corp.redhat.com [172.16.52.227]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j8RGNKV08609; Tue, 27 Sep 2005 12:23:20 -0400 Received: from greed.delorie.com (dj.cipe.redhat.com [10.0.0.222]) by post-office.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j8RGNJP24755; Tue, 27 Sep 2005 12:23:19 -0400 Received: from greed.delorie.com (greed.delorie.com [127.0.0.1]) by greed.delorie.com (8.13.1/8.13.1) with ESMTP id j8RGNIQQ017977; Tue, 27 Sep 2005 12:23:18 -0400 Received: (from dj@localhost) by greed.delorie.com (8.13.1/8.13.1/Submit) id j8RGNDDA017974; Tue, 27 Sep 2005 12:23:13 -0400 Date: Tue, 27 Sep 2005 18:04:00 -0000 Message-Id: <200509271623.j8RGNDDA017974@greed.delorie.com> From: DJ Delorie To: mark@codesourcery.com CC: gdb@sources.redhat.com, gdb-patches@sources.redhat.com, ian@airs.com In-reply-to: <43396939.4030602@codesourcery.com> (message from Mark Mitchell on Tue, 27 Sep 2005 08:46:01 -0700) 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> X-SW-Source: 2005-09/txt/msg00252.txt.bz2 > 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. 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? I also know that bfd itself has a rule that errors can't call exit; they must return error codes to the caller. This doesn't affect expandargv because bfd itself has no applications, but it's food for thought.