Re: [v2 1/4] coccinelle: api: extend memdup_user transformation with GFP_USER

[Markus Elfring]

>>>> * https://lore.kernel.org/cocci/5c0dae88-e172-3ba6-f86c-d1a6238bb4c4@xxxxxx/
>>>>   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