Messages in this thread | | | Subject | Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions | From | SF Markus Elfring <> | Date | Tue, 28 Nov 2017 13:13:51 +0100 |
| |
>> I am not going to “verify” your update suggestion by my evolving approaches >> around the semantic patch language (Coccinelle software) at the moment. > > As you are sending patches as Markus Elfring
I am contributing also some update suggestions.
> I would expect you take Coccinelle's suggestion into account
The proposed change is based on a semantic patch script which I developed with the support of other well-known Linux contributors.
> and actually try to understand code before sending patch.
I concentrated my understanding on the concrete transformation pattern in this use case.
> That suggestion may lead to actual bug in code which your patch just leaves > unnoticed as it is not apparent from the patch itself
There can be other change possibilities left over as usual.
> (no, not talking about this very patch it all started with)
Thanks for your distinction.
> That said, I'm considering Markus Elfring being a human.
Thanks for this view.
> If you do not like reactions to your patches
I am looking for constructive responses. - Disagreements can trigger special communication challenges.
> or are interested only in improving tool that generates them,
How do you think about to look at any more background information?
https://github.com/coccinelle/coccinelle/issues https://systeme.lip6.fr/pipermail/cocci/
> it would be better to just setup a "tip bot for Markus > Elfring" and let it send patches automatically.
There is already an other automatic source code analysis system active. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/scripts/coccinelle
> The way you are sending patches makes impression (at least to me), > that you spent some time on fixing issue Coccinelle found
Yes. - This view is appropriate.
> and not just shut the warning up.
Additional improvement possibilities can be taken into account after corresponding software development discussions, can't they?
Regards, Markus
| |