From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-50207-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 10417 invoked by alias); 9 Aug 2007 18:37:39 -0000
Received: (qmail 10407 invoked by uid 22791); 9 Aug 2007 18:37:38 -0000
X-Spam-Check-By: sourceware.org
Received: from a.mail.sonic.net (HELO a.mail.sonic.net) (64.142.16.245)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 09 Aug 2007 18:37:28 +0000
Received: from webmail.sonic.net (b.webmail.sonic.net [64.142.100.148]) 	by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l79IbQIu030374; 	Thu, 9 Aug 2007 11:37:26 -0700
Received: from 12.7.175.2         (SquirrelMail authenticated user msnyder)         by webmail.sonic.net with HTTP;         Thu, 9 Aug 2007 11:37:26 -0700 (PDT)
Message-ID: <9351.12.7.175.2.1186684646.squirrel@webmail.sonic.net>
In-Reply-To: <m3hcn9isrk.fsf@codesourcery.com>
References: <21906.12.7.175.2.1186283848.squirrel@webmail.sonic.net>     <m3y7go47sj.fsf@codesourcery.com>     <18682.12.7.175.2.1186597784.squirrel@webmail.sonic.net>     <m34pj9vgvr.fsf@codesourcery.com>     <22684.12.7.175.2.1186610277.squirrel@webmail.sonic.net>     <m3hcn9isrk.fsf@codesourcery.com>
Date: Thu, 09 Aug 2007 18:37:00 -0000
Subject: Re: [PATCH] solib_open, memory leak
From: msnyder@sonic.net
To: "Jim Blandy" <jimb@codesourcery.com>
Cc: gdb-patches@sourceware.org
User-Agent: SquirrelMail/1.4.9a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2007-08/txt/msg00180.txt.bz2

>
> msnyder@sonic.net writes:
>> [Jim:]
>>> The code clearly deserves a comment like:
>>>
>>>     /* We try to find the library in various ways.  After each
>>>        attempt, either found_file >= 0 and temp_pathname is a malloc'd
>>>        string, or found_file < 0 and temp_pathname does not point to
>>>        storage that needs to be freed.  */
>>>
>>> In that light, it seems clearer to me to just put:
>>>
>>>    if (found_file < 0)
>>>      temp_pathname = NULL;
>>>    else
>>>      temp_pathname = xstrdup (temp_pathname);
>>>
>>> immediately after the open, to make it obvious that the rule is
>>> followed there.
>>>
>> [...]
>>> Don't you want those new lines to replace the two that followed them,
>>> not just precede them?
>>
>> Yes, thanks.  How about this?
>
> Poifect.

Committed.