From: Derrick Stolee <derrickstolee@github.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] revision: mark blobs needed for resolve-undo as reachable
Date: Tue, 14 Jun 2022 10:35:10 -0400 [thread overview]
Message-ID: <31f406b1-b4e8-5da2-40af-5747938de634@github.com> (raw)
In-Reply-To: <220614.86czfcytlz.gmgdl@evledraar.gmail.com>
On 6/13/2022 8:24 PM, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Jun 13 2022, Derrick Stolee wrote:
>
>> On 6/9/2022 7:44 PM, Junio C Hamano wrote:
>>
>>> + struct string_list *resolve_undo = istate->resolve_undo;
>>> +
>>> + if (!resolve_undo)
>>> + return 0;
>>> +
>>> + for_each_string_list_item(item, resolve_undo) {
>>
>> I see this is necessary since for_each_string_list_item() does
>> not handle NULL lists. After attempting to allow it to handle
>> NULL lists, I see that the compiler complains about the cases
>> where it would _never_ be NULL, so that change appears to be
>> impossible.
>>
>> The patch looks good. I liked the comments for the three phases
>> of the test.
>
> I think it's probably good to keep for_each_string_list_item()
> implemented the way it is, given that all existing callers of it feed
> non-NULL lists to it.
We are talking right now about an example where it would be cleaner to
allow a NULL value.
This guarded example also exists in http.c (we would still need to guard
on NULL options):
/* Add additional headers here */
if (options && options->extra_headers) {
const struct string_list_item *item;
for_each_string_list_item(item, options->extra_headers) {
headers = curl_slist_append(headers, item->string);
}
}
These guarded examples in ref_filter_match() would be greatly simplified:
if (exclude_patterns && exclude_patterns->nr) {
for_each_string_list_item(item, exclude_patterns) {
if (match_ref_pattern(refname, item))
return 0;
}
}
if (include_patterns && include_patterns->nr) {
for_each_string_list_item(item, include_patterns) {
if (match_ref_pattern(refname, item))
return 1;
}
return 0;
}
if (exclude_patterns_config && exclude_patterns_config->nr) {
for_each_string_list_item(item, exclude_patterns_config) {
if (match_ref_pattern(refname, item))
return 0;
}
}
(The include_patterns check would still be needed for that extra
return 0; in the middle.)
There are more examples, but I'll stop listing them here.
> But why is it impossible to make it handle NULL lists? This works for
> me, and passes the tests:
> /** Iterate over each item, as a macro. */
> #define for_each_string_list_item(item,list) \
> - for (item = (list)->items; \
> + for (item = (((list) && (list)->items) ? ((list)->items) : NULL); \
I thinks I had something like
for ((list) && item = (list)->items; (list) && item && ...
but even with your suggestion, I get this compiler error:
In file included from convert.h:8,
from cache.h:10,
from apply.c:10:
apply.c: In function ‘write_out_results’:
string-list.h:146:22: error: the address of ‘cpath’ will always evaluate as ‘true’ [-Werror=address]
146 | for (item = ((list) && (list)->items) ? (list)->items : NULL; \
| ^
apply.c:4652:25: note: in expansion of macro ‘for_each_string_list_item’
4652 | for_each_string_list_item(item, &cpath)
|
(along with many other examples).
Junio is right that we would need to convert this into a method with a
function pointer instead of a for_each_* macro. That's quite a big lift
for some small convenience for the callers.
Thanks,
-Stolee
next prev parent reply other threads:[~2022-06-14 14:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-09 23:44 [PATCH] revision: mark blobs needed for resolve-undo as reachable Junio C Hamano
2022-06-13 15:15 ` Derrick Stolee
2022-06-13 20:11 ` Junio C Hamano
2022-06-14 0:24 ` Ævar Arnfjörð Bjarmason
2022-06-14 14:35 ` Derrick Stolee [this message]
2022-06-15 2:02 ` Taylor Blau
2022-06-15 3:48 ` Jeff King
2022-06-15 20:47 ` Taylor Blau
2022-06-15 17:11 ` Junio C Hamano
2022-06-16 14:10 ` Ævar Arnfjörð Bjarmason
2022-06-14 2:49 ` Taylor Blau
2022-07-11 8:19 ` fsck segfault (was: Re: [PATCH] revision: mark blobs needed for resolve-undo as reachable) SZEDER Gábor
2022-07-11 19:39 ` fsck segfault Junio C Hamano
2022-07-11 23:25 ` [PATCH 2/1] fsck: do not dereference NULL while checking resolve-undo data Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=31f406b1-b4e8-5da2-40af-5747938de634@github.com \
--to=derrickstolee@github.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).