From: Julia Lawall <julia.lawall@inria.fr>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: cocci@inria.fr
Subject: Re: [cocci] Reconsidering application of selected SmPL isomorphisms
Date: Mon, 25 Nov 2024 11:23:05 -0500 (EST) [thread overview]
Message-ID: <d05cde6b-6189-4c2-a452-a0851430dcb@inria.fr> (raw)
In-Reply-To: <100663c2-6281-49cb-bb9f-55656dff80ca@web.de>
[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]
On Mon, 25 Nov 2024, Markus Elfring wrote:
> > The generated code indeed does not look ideal. But it won't cause any
> > wrong matches.
>
> I got the impression that I would need to disable the isomorphism “paren”
> for the desired use case.
>
>
>
> > The isomorphisms are applied on the ASTs, not on the soure code.
>
> I remember other description approaches.
> Are isomorphisms usually mapped to SmPL disjunctions?
Yes. That is orthogonal to what I am saying. My point is that the way
that you see the code printed does not correspond to the actual internal
parse tree. The internal parse tree is the same as the original one, but
with the parentheses removed. There is no C source code that generates
such a parse tree, so the generated disjunction branch will not match
anything.
Some effort is made to accomodate !, but only when the isomorphism
contains ! applied to a metavariable, not for ! applied to more
complicated things.
>
>
> > So there will be a tree with a ! at the root and a || as the
> > argument that will not match any possible source code.
> >
> > Maybe it would be better to add isomorphisms for the de Morgan laws rather
> > than adding some hacks into the generic isomorphism transformation to take
> > this issue into account.
>
> I am looking for further software extensions.
>
> * I would occasionally like to restrict the source code search to pointer expressions.
expression *e;
> * Specifying a varying (or even unlimited) number of items for discussed boolean operators
e1 || ...
julia
next prev parent reply other threads:[~2024-11-25 16:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-25 13:16 [cocci] Reconsidering application of selected SmPL isomorphisms Markus Elfring
2024-11-25 15:37 ` Julia Lawall
2024-11-25 15:42 ` Julia Lawall
2024-11-25 16:13 ` Markus Elfring
2024-11-25 16:23 ` Julia Lawall [this message]
2024-11-25 16:34 ` Markus Elfring
2024-11-25 16:46 ` Julia Lawall
2024-11-25 16:57 ` [cocci] Advanced handling of logical operator chains (with SmPL)? Markus Elfring
2024-11-25 17:03 ` Julia Lawall
2024-11-25 17:08 ` Markus Elfring
2024-11-25 17:04 ` [cocci] Data processing challenges for pointer expressions Markus Elfring
2024-11-25 17:16 ` Julia Lawall
2024-11-25 17:58 ` Markus Elfring
2024-11-26 9:21 ` [cocci] Data processing challenges for source code analyses 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=d05cde6b-6189-4c2-a452-a0851430dcb@inria.fr \
--to=julia.lawall@inria.fr \
--cc=Markus.Elfring@web.de \
--cc=cocci@inria.fr \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).