On Tue, Apr 29, 2014 at 12:18 PM, Ronnie Sahlberg <sahlberg@xxxxxxxxxx> wrote:
> On Mon, Apr 28, 2014 at 5:44 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>> On Mon, Apr 28, 2014 at 6:54 PM, Ronnie Sahlberg <sahlberg@xxxxxxxxxx> wrote:
>>> Update replace.c to use ref transactions for updates.
>>>
>>> Signed-off-by: Ronnie Sahlberg <sahlberg@xxxxxxxxxx>
>>> ---
>>> builtin/replace.c | 14 ++++++++------
>>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/builtin/replace.c b/builtin/replace.c
>>> index b62420a..b037b29 100644
>>> --- a/builtin/replace.c
>>> +++ b/builtin/replace.c
>>> @@ -129,7 +129,8 @@ static int replace_object(const char *object_ref, const char *replace_ref,
>>> unsigned char object[20], prev[20], repl[20];
>>> enum object_type obj_type, repl_type;
>>> char ref[PATH_MAX];
>>> - struct ref_lock *lock;
>>> + struct ref_transaction *transaction;
>>> + struct strbuf err = STRBUF_INIT;
>>>
>>> if (get_sha1(object_ref, object))
>>> die("Failed to resolve '%s' as a valid ref.", object_ref);
>>> @@ -157,11 +158,12 @@ static int replace_object(const char *object_ref, const char *replace_ref,
>>> else if (!force)
>>> die("replace ref '%s' already exists", ref);
>>>
>>> - lock = lock_any_ref_for_update(ref, prev, 0, NULL);
>>> - if (!lock)
>>> - die("%s: cannot lock the ref", ref);
>>> - if (write_ref_sha1(lock, repl, NULL) < 0)
>>> - die("%s: cannot update the ref", ref);
>>> + transaction = ref_transaction_begin();
>>> + if (!transaction ||
>>> + ref_transaction_update(transaction, ref, repl, prev,
>>> + 0, !is_null_sha1(prev)) ||
>>> + ref_transaction_commit(transaction, NULL, &err))
>>> + die(_("%s: failed to replace ref: %s"), ref, err.buf);
>>
>> Even though 'err' will be empty after this conditional, would
>> strbuf_release(&err) here be warranted to future-proof it? Today's
>> implementation of strbuf will not have allocated any memory, but
>> perhaps a future change might pre-allocate (unlikely though that is),
>> which would leak here.
>
> I have no strong feelings either way.
> A previous patch got a comment to remove a strbuf_release() because we
> knew in that
> code path that the string would be empty and thus the call was superfluous.
Indeed, I realized later that the reason I gave for possibly adding
the strbuf_release() was effectively bogus. Code throughout the
project ignores strbuff_release() when it is obvious that the strbuf
hasn't been used. Such code looks like this:
func() {
struct strbuf foo = STRBUF_INIT;
...code not touching 'foo'...
if (...)
return;
...code touching 'foo'...
strbuf_release(&foo);
}
At the point of early return, it's obvious at a glance that no content
has been added to 'foo'.
It was only a little while ago that I came to understand why the code
in this patch bothered me:
func() {
struct strbuf foo = STRBUF_INIT;
if (bar(&foo))
die(...);
...return or fall off end without releasing 'foo'...
}
The problem is that it's not so easy to see that it's safe to "leak"
the strbuf without detouring through the documentation of bar() and
possibly its implementation as well, before finally resuming the
reading of func(). That extra cost of having to study bar() will
likely be paid by most readers of func() who are concerned about the
missing strbuf_release(). The cognitive burden is greater.
> So one for and one against so far.
> I will leave as is until there is more consensus.
Fair enough. The fact that the variable is named 'err' in this case
might be enough to allow one to infer, without detouring through
bar(), that the missing strbuf_release() is intentional.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html