linux-kernel - Re: [4/5] Coccinelle: put_device: Extend when constraints for two SmPL ellipses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2881b53d-66ba-1327-0081-42f7c853b79e@web.de>
Date:   Tue, 14 May 2019 09:49:38 +0200
From:   Markus Elfring <Markus.Elfring@....de>
To:     Julia Lawall <julia.lawall@...6.fr>,
        Wen Yang <wen.yang99@....com.cn>
Cc:     Gilles Muller <Gilles.Muller@...6.fr>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nicolas Palix <nicolas.palix@...g.fr>, cocci@...teme.lip6.fr,
        linux-kernel@...r.kernel.org, Yi Wang <wang.yi59@....com.cn>
Subject: Re: [4/5] Coccinelle: put_device: Extend when constraints for two
 SmPL ellipses

>> Can you agree to any information which I presented in the commit message?

Do you find this description inappropriate?

>>> You don't need so many type metavariables.
>>
>> It seems that the Coccinelle software can cope also with my SmPL code addition.
>> You might feel uncomfortable with the suggested changes for a while.
>
> It's ugly.  Much more ugly than msg =

The clarification of this change reluctance might become more interesting.
I got convinced that there is a need for further software updates.

>> * Can it become required to identify involved source code placeholders
>>   by extra metavariables?
>
> I don't understand the question.

Wen Yang was planning a corresponding modification since 2019-02-19.
https://lore.kernel.org/cocci/201902191014156680299@zte.com.cn/
https://systeme.lip6.fr/pipermail/cocci/2019-February/005620.html

I got into the development mood to contribute another concrete update suggestion
for an open issue in affected scripts for the semantic patch language.
Do you recognise the need for the extension of exclusion specifications here?

>> * Would you like to clarify the probability any more how often the shown
>>   type casts will be identical?
>
> No idea about this one either.

I am curious if helpful ideas will be added also by other contributors.

> Basically, if you have T && T, the two T's have to be the same,

Such an expectation might be logical.

> and T is not pure.

This information triggers various communication difficulties.

> If you have T on two separate ...s then you are in the && case.

I agree to this view also according the application of two ellipses
in the SmPL rule “search”.

> If you have T in two branches of a disjunction or in two whens on the same
> ... you are in the || case.

It is clear that disjunctions will check code alternatives here.
The clarification of consequences around the interpretation of “type purity”
might distract from the final solution.

How many (optional) type casts would we like to handle by the discussed
source code search approach?

Regards,
Markus