# [PATCH 2/4] make filepairs detachable 5 messages from 2006-06-30 to 2006-06-30. Participants: Alex Riesen, Junio C Hamano. Thread: https://gitlist.dev/t/4713 ## Alex Riesen, 2006-06-30 00:27 Subject: [PATCH 2/4] make filepairs detachable Message-ID: <20060630002736.GB22618@steel.home> URL: https://gitlist.dev/e/20060630002736.GB22618%40steel.home ``` Actually, just make sure diff_flush does not crash for diff queue entries which were cleared. --- diff.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/diff.c b/diff.c index 5a71489..b3480f6 100644 --- a/diff.c +++ b/diff.c @@ -2281,6 +2281,8 @@ void diff_flush(struct diff_options *opt } for (i = 0; i < q->nr; i++) { struct diff_filepair *p = q->queue[i]; + if (!p) + continue; flush_one_pair(p, diff_output_format, options, diffstat); } @@ -2290,6 +2292,8 @@ void diff_flush(struct diff_options *opt } for (i = 0; i < q->nr; i++) { + if (!q->queue[i]) + continue; if (diffstat && options->summary) diff_summary(q->queue[i]); diff_free_filepair(q->queue[i]); -- 1.4.1.rc1.g17dc ``` ## Junio C Hamano, 2006-06-30 01:16 Subject: Re: [PATCH 2/4] make filepairs detachable Message-ID: <7vy7vfmoit.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vy7vfmoit.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060630002736.GB22618@steel.home> ``` fork0@t-online.de (Alex Riesen) writes: > Actually, just make sure diff_flush does not crash for diff queue > entries which were cleared. Somehow I really feel uneasy about this one. I think it is the responsibility of the one who mangles the queue to adjust the entries and count consistent. ``` ## Alex Riesen, 2006-06-30 07:42 Subject: Re: [PATCH 2/4] make filepairs detachable Message-ID: <81b0412b0606300042r24931d9i5fad0e849b8de84c@mail.gmail.com> URL: https://gitlist.dev/e/81b0412b0606300042r24931d9i5fad0e849b8de84c%40mail.gmail.com In-Reply-To: <7vy7vfmoit.fsf@assigned-by-dhcp.cox.net> ``` On 6/30/06, Junio C Hamano wrote: > > > Actually, just make sure diff_flush does not crash for diff queue > > entries which were cleared. > > Somehow I really feel uneasy about this one. I think it is the > responsibility of the one who mangles the queue to adjust the > entries and count consistent. > That's what I get after being exposed to double-linked lists for too long: I begin to think it's fine to take whatever I want. The pairs are actually exactly what I need, so I take them. I think I just have to encapsulate it nicely, i.e.: struct diff_filepair *diff_queued_detach(int pos) { struct diff_filepair *pair = NULL; if (pos < diff_queued_diff.nr) { diff_queued_diff.queue[pos]; if (diff_queued_diff.nr - pos > 1) memmove(pair->queue + pos, pair->queue + pos + 1, diff_queued_diff.nr - pos - 1); diff_queued_diff.nr--; } return pair; } BTW, is there any chance we get the struct diff_filepair's double-linked? They don't seem to be sorted. Will increase the memory footprint, though. ``` ## Junio C Hamano, 2006-06-30 07:50 Subject: Re: [PATCH 2/4] make filepairs detachable Message-ID: <7v7j2zkrod.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v7j2zkrod.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <81b0412b0606300042r24931d9i5fad0e849b8de84c@mail.gmail.com> ``` "Alex Riesen" writes: > BTW, is there any chance we get the struct diff_filepair's > double-linked? They don't seem to be sorted. Will increase > the memory footprint, though. You do not necessarily have to do things in place. In fact, all of the standard diffcore transformers create a new queue, read from the old queue and place the filtered or munged result in the new queue, swap the global queued_diff variable to point at the new one and discard the old queue. See diff.c::diffcore_apply_filter() for the simplest example. ``` ## Alex Riesen, 2006-06-30 08:21 Subject: Re: [PATCH 2/4] make filepairs detachable Message-ID: <81b0412b0606300121q4148dfb0qb5915bd029d72f44@mail.gmail.com> URL: https://gitlist.dev/e/81b0412b0606300121q4148dfb0qb5915bd029d72f44%40mail.gmail.com In-Reply-To: <7v7j2zkrod.fsf@assigned-by-dhcp.cox.net> ``` On 6/30/06, Junio C Hamano wrote: > > > BTW, is there any chance we get the struct diff_filepair's > > double-linked? They don't seem to be sorted. Will increase > > the memory footprint, though. > > You do not necessarily have to do things in place. In fact, all > of the standard diffcore transformers create a new queue, read > from the old queue and place the filtered or munged result in > the new queue, swap the global queued_diff variable to point at > the new one and discard the old queue. > > See diff.c::diffcore_apply_filter() for the simplest example. > I see. Looks dangerous outside of diff.c though. ```