cocci.inria.fr archive mirror
 help / color / mirror / Atom feed
From: Markus Elfring <Markus.Elfring@web.de>
To: Julia Lawall <julia.lawall@lip6.fr>, Wen Yang <wen.yang99@zte.com.cn>
Cc: kernel-janitors@vger.kernel.org,
	Michal Marek <michal.lkml@markovi.net>,
	Wen Yang <yellowriver2010@hotmail.com>,
	Nicolas Palix <nicolas.palix@imag.fr>,
	linux-kernel@vger.kernel.org,
	Cheng Shengyu <cheng.shengyu@zte.com.cn>,
	cocci@systeme.lip6.fr
Subject: Re: [Cocci] [v6] coccinelle: semantic code search for missing put_device()
Date: Mon, 18 Feb 2019 09:19:30 +0100	[thread overview]
Message-ID: <ab463e94-287a-6188-6795-06eeb832e861@web.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1902180740550.3111@hadrien>

>>> Which data element should not get reassigned here (before a corresponding
>>> null pointer check)?
>>>
>>
>> Thank you for your comments.
>> We did some experiments:
>> +id = of_find_device_by_node@p1(x)
>> +... when != e = id
>> ...
>> Or:
>> ...
>> + ... when != id = e
>>
>> The number of issuses found by these two methods is the same.

This can be because these SmPL specifications share some source code search functionality.


>> When != e = id achieves this behavior.
>
> They are the same because neither issue arises.

You might not notice a difference from a specific source file selection so far.


> I would have a hard time saying which one is more reasonable to test,

I suggest to reconsider the interpretation of this software situation once more.


> since both are extremely unlikely.

I disagree to this view because two ellipses were intentionally specified
in published SmPL scripts.
So some software developers found these “special use cases” important enough.


>> In addition, we feel that we should probably accept this patch first,

I disagree to this imagination because I would prefer to integrate a source code variant
without a bug (which was copied from a version on 2013-05-08 by Petr Strnad).
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/free/pci_free_consistent.cocci?id=f7b167113753e95ae61383e234f8d10142782ace#n12

I hope that nicer run time behaviour can become also relevant here.


>> use it to find more memory leaks, and solve the actual problems in the kernel code.

Your are not hindered to achieve specific software improvements with evolving
development approaches while the clarification and the final integration
of useful scripts for the semantic patch language can take a bit longer.


>> As for the patch itself, we can continue to pursue perfect in the process
>> of using it to solve practical problems.

I am curious on how your attention will evolve further for the corresponding
software correctness.

1. How much will you care for the order of identifiers within the application
   of SmPL assignment exclusions?

2. Would you like to take additional data type restrictions into account?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

  reply	other threads:[~2019-02-18  8:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-16 16:05 [Cocci] [PATCH v6] coccinelle: semantic code search for missing put_device() Wen Yang
2019-02-16 16:33 ` Julia Lawall
2019-02-16 18:39 ` [Cocci] [v6] " Markus Elfring
2019-02-17  2:32   ` [Cocci] 答复: " Wen Yang
2019-02-17  7:42     ` Markus Elfring
2019-02-17  9:50 ` [Cocci] [PATCH v6] " Markus Elfring
2019-02-17 11:37   ` Julia Lawall
2019-02-17 11:42     ` Markus Elfring
2019-02-17 11:48       ` Julia Lawall
2019-02-17 12:00         ` [Cocci] [v6] " Markus Elfring
2019-02-17 12:05           ` Julia Lawall
2019-02-17 12:20             ` Markus Elfring
2019-02-17 12:52               ` Julia Lawall
2019-02-17 13:14                 ` Markus Elfring
2019-02-18  3:22                   ` wen.yang99
2019-02-18  6:43                     ` Julia Lawall
2019-02-18  8:19                       ` Markus Elfring [this message]
2019-02-19  2:14                         ` wen.yang99
2019-02-19  7:04                           ` Julia Lawall
2019-02-19  8:12                             ` Markus Elfring
2019-02-19  8:29                           ` Markus Elfring
2019-02-19  9:09                             ` wen.yang99
2019-02-19  9:30                               ` Markus Elfring
2019-03-06 11:18                           ` Markus Elfring
2019-02-18 21:40                     ` Markus Elfring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ab463e94-287a-6188-6795-06eeb832e861@web.de \
    --to=markus.elfring@web.de \
    --cc=cheng.shengyu@zte.com.cn \
    --cc=cocci@systeme.lip6.fr \
    --cc=julia.lawall@lip6.fr \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=nicolas.palix@imag.fr \
    --cc=wen.yang99@zte.com.cn \
    --cc=yellowriver2010@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).