From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-93607-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 43781 invoked by alias); 25 Jun 2018 20:43:19 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 43750 invoked by uid 89); 25 Jun 2018 20:43:18 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=
X-HELO: mx1.redhat.com
Subject: Re: [PATCH] _nss_nis_initgroups_dyn: Use struct scratch_buffer [BZ
 #18023]
To: DJ Delorie <dj@redhat.com>
Cc: libc-alpha@sourceware.org
References: <xnr2kuk3gd.fsf@greed.delorie.com>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <7fdc44e1-6e74-9a11-678e-db3298ee3a87@redhat.com>
Date: Mon, 25 Jun 2018 20:43:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <xnr2kuk3gd.fsf@greed.delorie.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2018-06/txt/msg00761.txt.bz2

On 06/25/2018 10:37 PM, DJ Delorie wrote:
> 
> fweimer@redhat.com (Florian Weimer) writes:
>> -      buf = extend_alloca (buf, buflen, 2 * buflen);
>> +      if (!scratch_buffer_grow (&tmpbuf))
>> +	return 1;
> 
> The docs say if _grow() fails, the buffer is still free'able.  Could we
> not, or should we, use "break" here so that scratch_buffer_free() is
> called when grow() fails?
> 
> The docs (scratch_buffer.h) mentions that the old buffer is freed, but
> that the scratch_buffer is still "in a freeable state" so it's not clear
> if the intention is that you *should* call scratch_buffer_free(), or
> *must*, or *must not*, etc.

You can free the buffer again, but you don't have to.  There is no 
memory leak if you don't.

> 
>>       }
>>   
>> +  scratch_buffer_free (&tmpbuf);
>>     return 1;
>>   }

The point here is not call free if we know it is a no-op.

So I think the code is okay as-is.

>> +	if (!scratch_buffer_grow (&tmpbuf))
>> +	  {
>> +	    status = NSS_STATUS_TRYAGAIN;
>> +	    goto done;
>> +	  }
> 
> In this case, going to "done" *does* call scratch_buffer_free().  At
> least we should be consistent within a given file ;-)

Here we call the entire cleanup sequence, which happens to include 
scratch_buffer_free as well, so the situation is different.

I hope this clarifies why things are the way they are.

Thanks,
Florian