Messages in this thread | | | Subject | Re: [v2 1/4] coccinelle: api: extend memdup_user transformation with GFP_USER | From | Markus Elfring <> | Date | Sat, 18 Jul 2020 11:16:04 +0200 |
| |
>>>> * https://lore.kernel.org/cocci/5c0dae88-e172-3ba6-f86c-d1a6238bb4c4@web.de/ >>>> https://lkml.org/lkml/2020/6/9/568 >>> >>> This one it complete nonsense. >> >> I hope that different views can be clarified for such a software situation >> in more constructive ways. > > You proposed essentially \( A \| B \) \( | C \| \)
I suggested also another adjustment.
Can additional minus characters be avoided if such a source code search pattern would be specified in a single line?
> This is not valid syntax in the semantic patch language.
I hope that a solution can be found by our discussion.
> The branches of a \( \| \) have to be a valid expression, statement, type, etc,
Such information can become more interesting for safe application of SmPL disjunctions.
> not some random string of tokens.
I got further imaginations in this software area.
Will the handling of optional transformation parameters be clarified better?
>> Patch reviews contain usual risks that suggestions are presented >> which can be still questionable. > > These are not "usual risks". You can easily test out your suggestion by > yourself to see if it produces valid code.
Such an expectation can be reasonable in some cases.
> If it doesn't, then don't make the suggestion.
Would software limitations hinder any more improvements then?
>>> like that putting all of the virtual declarations on >>> the same line would save space (it does, but who cares), >> >> It seems that you admit a possibly desirable effect. > > No, I don't consider the effect to be desirable.
I propose to take another look at variations around source code verbosity.
>> Your change acceptance is varying to your development mood >> (and other factors), isn't it? > > Not really. My "change acceptance" increases when the person reporting > them raises real problems that is blocking them in some work.
I presented open issues accordingly.
> And it decreases rapidly when the changes are almost all related to presumed > "efficiencies" that have no impact in practice.
Change possibilities can get varying attention and corresponding development priorities.
Regards, Markus
| |