From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Wed, 02 Apr 2014 13:37:14 GMT
Subject: Re: [PATCH 21/22] lockfile: extract a function reset_lock_file()
Message-ID: <533C128A.9020406@alum.mit.edu>
In-Reply-To: <CAPig+cTEC6kgmgCcpcjaRNMf3gQVQGzBQx5i5A+EuDppH9VQxg@mail.gmail.com>

On 04/02/2014 09:06 AM, Eric Sunshine wrote:
> On Tue, Apr 1, 2014 at 11:58 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
>> ---
>>  lockfile.c | 31 ++++++++++++++++---------------
>>  1 file changed, 16 insertions(+), 15 deletions(-)
>>
>> diff --git a/lockfile.c b/lockfile.c
>> index 852d717..c06e134 100644
>> --- a/lockfile.c
>> +++ b/lockfile.c
>> @@ -85,6 +85,14 @@ static void remove_lock_file_on_signal(int signo)
>>         raise(signo);
>>  }
>>
>> +static void reset_lock_file(struct lock_file *lk)
>> +{
>> +       lk->fd = -1;
>> +       strbuf_setlen(&lk->filename, 0);
>> +       strbuf_setlen(&lk->staging_filename, 0);
> 
> strbuf_reset() perhaps?

Thanks, Eric.  For some reason I always have it in the back of my head
that strbuf_reset() frees the memory associated with the strbuf, but of
course that is strbuf_release() that I'm thinking of.

I just fixed all strbuf_setlen(..., 0) -> strbuf_reset(...) throughout
the patch series.  The fix will be in the re-roll.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/