Re: [PATCH 01/23] contrib/coccinnelle: add equals-null.cocci

Philip Oakley [off-list ref] writes:

quoted

quoted

As I assumed that applying the patches in this series would create
the branch B, and then I saw that the tip of 'seen' after merging
this topic still needed to have a lot more fixes according to "make
coccicheck", I got a (false) impression that there are too many new
violations from topics in flight, which was the primary source of my
negative reaction against potential code churn.  If we try the above
exercise, perhaps there may not be too many topics that need fix-up
beyond what we fix in the branch B, and if that is the case, I would
not be so negative.

So I tried that myself, and the topic branch B was fairly
straightforward to create.

We have ~60 topics in flight (not counting this one), and it turns
out that there is no topic that introduces new code that fails the
equals-null.cocci rule.  IOW, the follow-up fixup per topic turns
out to be an empty set.

So, I'd probably use the [01/23] and then a single ~5k lines patch
that was generated with equals-null.cocci rule as the branch B
above, let it percolate down from 'seen' to 'next' to eventually
'master'.

Thanks.

That sounds like a good result.

It may also be worth Elia cross checking against a previous release
(v2.35.0?) for relatively recent introductions, to cover the potential
revert scenario, just in case..

Sounds sensible.  We do have some changes between 2.35 and 2.36 and
the fork-points of many topics predate 2.36 (and may even 2.35).

Here is an experiment I just did:

 * Applied the patch to add equals-null.cocci to maint-2.35.

 * Ran "coccicheck", applied the resulting equals-null fix and
   committed the result.

 * Merged the "branch B" from last night to it.

The resulting tree exactly matched "branch B" (i.e. 2.36.0 fixed
with equals-null.cocci check).

If I instead merge vanilla 2.36 with the result of fixing
maint-2.35, that differs at two places from "branch B" (i.e. we
added two new violations to 2.36 relative to 2.35).

Doing the same between maint-2.35 and maint-2.34 seems to indicate
that we didn't add any new violations during that period.

So in short, 2.35 may probably be a good place to start, but basing
on 2.36 seems to be good enough.

Thanks.

 branch.c                             | 2 +-
 compat/fsmonitor/fsm-listen-darwin.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git c/branch.c w/branch.c
index bde705b092..d0ca2b76d2 100644
--- c/branch.c
+++ w/branch.c

@@ -653,7 +653,7 @@ void create_branches_recursively(struct repository *r, const char *name,
 	 * be created in every submodule.
 	 */
 	for (i = 0; i < submodule_entry_list.entry_nr; i++) {
-		if (!submodule_entry_list.entries[i].repo) {
+		if (submodule_entry_list.entries[i].repo == NULL) {
 			int code = die_message(
 				_("submodule '%s': unable to find submodule"),
 				submodule_entry_list.entries[i].submodule->name);

diff --git c/compat/fsmonitor/fsm-listen-darwin.c w/compat/fsmonitor/fsm-listen-darwin.c
index dc8a33130a..0741fe834c 100644
--- c/compat/fsmonitor/fsm-listen-darwin.c
+++ w/compat/fsmonitor/fsm-listen-darwin.c

@@ -342,7 +342,7 @@ int fsm_listen__ctor(struct fsmonitor_daemon_state *state)
 					   data->cfar_paths_to_watch,
 					   kFSEventStreamEventIdSinceNow,
 					   0.001, flags);
-	if (!data->stream)
+	if (data->stream == NULL)
 		goto failed;
 
 	/*