On 5/1/2022 1:00 AM, Junio C Hamano wrote: > 13092a91 (cocci: refactor common patterns to use xstrdup_or_null(), > 2016-10-12) introduced a rule to rewrite this conditional call to > xstrdup(E) and an assignment to variable V: > > - if (E) > - V = xstrdup(E); > > into an unconditional call to xstrdup_or_null(E) and an assignment > to variable V: > > + V = xstrdup_or_null(E); > > which is utterly bogus. The original code may already have an > acceptable value in V and the conditional assignment may be to > improve the value already in V with a copy of a better value E when > (and only when) E is not NULL. Yes, this makes sense. > The rewritten construct unconditionally discards the existing value > of V and replaces it with a copy of E, even when E is NULL, which > changes the meaning of the program. > > By the way, if it were > > -if (E && !V) > - V = xstrdup(E); > +V = xstrdup_or_null(E); I think you mean if it were -if (E && !V) - V = xstrdup(E); +if (!V) + V = xstrdup_or_null(E); or -if (E && !V) - V = xstrdup(E); +free(V); +V = xstrdup_or_null(E); But yes, there is no preimage matching this pattern, so it doesn't matter. Dropping the rule makes the most sense. Thanks, -Stolee