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: <66250f72-c433-28c7-a224-6f248339ec4c@web.de>
Date:   Mon, 13 May 2019 14:22:44 +0200
From:   Markus Elfring <Markus.Elfring@....de>
To:     Julia Lawall <julia.lawall@...6.fr>
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>,
        Wen Yang <wen.yang99@....com.cn>, 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

>> Take additional casts for these code exclusion specifications into account
>> together with optional parentheses.
>
> NACK.

I find this rejection surprising.

> You don't need so many type metavariables.

I got an other software development opinion for this aspect.

Yesterday we started to clarify consequences from the isomorphism specification
“drop_cast” (for SmPL code).
https://github.com/coccinelle/coccinelle/blob/32d3b89ad909316464344a5f61a8092d8d702321/standard.iso#L52

Information like the following influenced my design decision to add three
metavariables here.

elfring@...ne:~/Projekte/Linux/next-patched> spatch --parse-cocci scripts/coccinelle/free/put_device.cocci
…
warning: iso drop_cast does not match the code below on line -1
T (T )id

pure metavariable T is matched against the following nonpure code:
T
…

> Type metavariables in the same ... can be the same.

I would find it also occasionally nice when multiple SmPL ellipses
can refer to identical type casts.

* The under-documented “type purity” hinders this at the moment.

* But I got the impression that it can be safer to distinguish these
  code variants better.

Regards,
Markus