Re: [PATCH 01/11] sha1_file: do not leak `lock_file`
- From
- Martin Ågren <martin.agren@gmail.com>
- Date
- Oct 2, 2017, 10:15 UTC
- Message-ID
- <CAN0heSotumvyYDa8zsRx9cNd8LF+CgUOGgd+eFPEmwBqJsjfkA@mail.gmail.com>
- In-Reply-To
- <20171002052659.hgzkhz4sgez3mkgz@sigill.intra.peff.net>
On 2 October 2017 at 07:26, Jeff King <peff@peff.net> wrote:
Show 36 quoted lines
> On Sun, Oct 01, 2017 at 04:56:02PM +0200, Martin Ågren wrote:
>
> The original code is actually a bit confusing/unsafe, as we set the
> "found" flag early and rollback here:
>
>> @@ -481,17 +481,15 @@ void add_to_alternates_file(const char *reference)
>> strbuf_release(&line);
>> fclose(in);
>>
>> - if (found) {
>> - rollback_lock_file(lock);
>> - lock = NULL;
>> - }
>> + if (found)
>> + rollback_lock_file(&lock);
>
> and that leaves the "out" filehandle dangling. It's correct because of
> the later "do we still have the lock" check:
>
>> - if (lock) {
>> + if (is_lock_file_locked(&lock)) {
>> fprintf_or_die(out, "%s\n", reference);
>
> but the two spots must remain in sync. If I were writing it from scratch
> I might have bumped "found" to the scope of the whole function, and then
> replaced this final "do we still have the lock" with:
>
> if (found)
> rollback_lock_file(&lock);
> else {
> fprintf_or_die(out, "%s\n", reference);
> if (commit_lock_file(&lock))
> ...etc...
> }
>
> I don't know if it's worth changing now or not.I'd like to address the feedback on other commits in a re-roll. I will use that opportunity to try your approach above instead of this patch.
Thanks.