From: Julia Lawall <julia.lawall@inria.fr>
To: Kees Cook <keescook@chromium.org>
Cc: cocci@inria.fr, linux-hardening@vger.kernel.org,
"Gustavo A. R. Silva" <gustavoars@kernel.org>
Subject: Re: [cocci] spatch --jobs N missing matches?
Date: Wed, 28 Sep 2022 07:23:44 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.22.394.2209280722150.2844@hadrien> (raw)
In-Reply-To: <202209271425.50502D365C@keescook>
On Tue, 27 Sep 2022, Kees Cook wrote:
>
> On Tue, Sep 27, 2022 at 11:09:35PM +0200, Julia Lawall wrote:
> > The problem is fixed in github. Coccinelle was doing some caching of
> > header files, that was not desirable in the case where one actually wants
> > to match the code, and not just get type information.
>
> Thank you for the fix! I can confirm things appear to be working
> correctly now. (And took 124 minutes to run.)
OK, long, but at least you get the result.
> > [...]
> > Actually, there are not that many memcpys in the considered code. Then
> > there are not that many that refer to the last element of a structure. If
> > level2 produces nothing, then level 1 should not be applied.
> >
> > In the original rule order, all of the pairs of a flexible structure and
> > any structure are considered, regardless of whether any memcpys are
> > present.
>
> Ah! Yes, I keep forgetting to start with the narrowest part first. :P
>
> I also forget that I can do a "depends" on something that has no other
> matches, but if it's built on prior rules that I use in later rules,
> then it limits that rule directly. I haven't quite managed to think
> sideways hard enough. :)
Actually, that is the only purpose of depends on. Your original rule had
a depends on level2 that was unnecessary, since the rule couldn't match if
some metavariables from level2 were not bound.
julia
prev parent reply other threads:[~2022-09-28 5:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-26 18:52 [cocci] spatch --jobs N missing matches? Kees Cook
2022-09-26 21:14 ` Julia Lawall
2022-09-26 22:09 ` Kees Cook
2022-09-27 20:37 ` Julia Lawall
2022-09-27 21:09 ` Julia Lawall
2022-09-28 0:06 ` Kees Cook
2022-09-28 5:23 ` Julia Lawall [this message]
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=alpine.DEB.2.22.394.2209280722150.2844@hadrien \
--to=julia.lawall@inria.fr \
--cc=cocci@inria.fr \
--cc=gustavoars@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.