From: Taylor Blau <me@ttaylorr.com>
To: Jeff King <peff@peff.net>
Cc: "Taylor Blau" <me@ttaylorr.com>,
"Derrick Stolee" <derrickstolee@github.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Junio C Hamano" <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: [PATCH] revision: mark blobs needed for resolve-undo as reachable
Date: Wed, 15 Jun 2022 16:47:26 -0400 [thread overview]
Message-ID: <YqpFXoKPu2E1j+mr@nand.local> (raw)
In-Reply-To: <YqlWhKDFX3KESY0h@coredump.intra.peff.net>
On Tue, Jun 14, 2022 at 11:48:20PM -0400, Jeff King wrote:
> On Tue, Jun 14, 2022 at 10:02:32PM -0400, Taylor Blau wrote:
>
> > --- >8 ---
> >
> > diff --git a/string-list.h b/string-list.h
> > index d5a744e143..425abc55f4 100644
> > --- a/string-list.h
> > +++ b/string-list.h
> > @@ -143,7 +143,7 @@ int for_each_string_list(struct string_list *list,
> >
> > /** Iterate over each item, as a macro. */
> > #define for_each_string_list_item(item,list) \
> > - for (item = (list)->items; \
> > + for (item = (list) ? (list)->items : NULL; \
> > item && item < (list)->items + (list)->nr; \
> > ++item)
> >
> > --- 8< ---
> >
> > > but even with your suggestion, I get this compiler error:
> >
> > ...so did I. Though I'm not sure I understand the compiler's warning
> > here. Surely the thing being passed as list in the macro expansion
> > _won't_ always evaluate to non-NULL, will it?
>
> In the general case, no, but in this specific expansion of the macro, it
> is passing the address of a local variable (&cpath), which will never be
> NULL. The compiler is overeager here; the check is indeed pointless in
> this expansion, but warning on useless macro-expanded code isn't
> helpful, since other macro users need it.
Ah, that makes sense. The compiler is warning us that the macro-expanded
version of for_each_string_list_item() has a ternary expression that
will never evaluate its right-hand side in cases where it can prove the
second argument to the macro is non-NULL.
> Hiding it in a function seems to work, even with -O2 inlining, like:
>
> diff --git a/string-list.h b/string-list.h
> index d5a744e143..b28b135e11 100644
> --- a/string-list.h
> +++ b/string-list.h
> @@ -141,9 +141,14 @@ void string_list_clear_func(struct string_list *list, string_list_clear_func_t c
> int for_each_string_list(struct string_list *list,
> string_list_each_func_t func, void *cb_data);
>
> +static inline struct string_list_item *string_list_first_item(const struct string_list *list)
> +{
> + return list ? list->items : NULL;
> +}
> +
> /** Iterate over each item, as a macro. */
> #define for_each_string_list_item(item,list) \
> - for (item = (list)->items; \
> + for (item = string_list_first_item(list); \
> item && item < (list)->items + (list)->nr; \
> ++item)
That works, nice. I don't really want to mess up the tree too much this
close to a release, but this sort of clean-up seems good to do. I know
Stolee identified a handful of spots that would benefit from it. Some
good #leftoverbits, I guess :-).
Thanks,
Taylor
next prev parent reply other threads:[~2022-06-15 20:50 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
2022-06-15 2:02 ` Taylor Blau
2022-06-15 3:48 ` Jeff King
2022-06-15 20:47 ` Taylor Blau [this message]
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=YqpFXoKPu2E1j+mr@nand.local \
--to=me@ttaylorr.com \
--cc=avarab@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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).