The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Julia Lawall <julia.lawall@lip6.fr>
To: SF Markus Elfring <elfring@users.sourceforge.net>
Cc: Julia Lawall <julia.lawall@lip6.fr>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Gilles Muller <Gilles.Muller@lip6.fr>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Michal Marek <mmarek@suse.com>,
	Nicolas Palix <nicolas.palix@imag.fr>,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
	cocci@systeme.lip6.fr
Subject: Re: [PATCH] coccinelle: assign signed result to unsigned variable
Date: Sat, 26 Sep 2015 17:30:46 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1509261728140.2864@hadrien> (raw)
In-Reply-To: <5606B837.7030608@users.sourceforge.net>

On Sat, 26 Sep 2015, SF Markus Elfring wrote:

> > It doesn't matter, as long as the type is available.
>
> I suggest to make the circumstances better known when this will be the case.

It is like for the type of anything.  If the declaration of the thing is
available with the type information, eg in the same file or an included
header file, then the type will be available.  If the declaration is not
available then the type will not be available.

> >> How do you think about reuse another data type enumeration there?
> >
> > No idea what you mean by this.
>
> A SmPL variable can also be connected with a data type list which is
> discussed here.

One type, more that one type, it doesn't matter.

> >> How would you like to manage names for functions which are not defined
> >> in the current source file?
> >
> > Why does it matter in this case?
>
> * Will a command-line parameter like "--include-headers-for-types"
>   be needed here?

This argument is never needed.  It is only an optimization.  It means that
he header files are only considered when collecting type information, but
not whn doing transformation.  But this argument has no effect on the set
of types tha are available.

julia

> * Would it make sense to work with function name lists in SmPL constraints?
>
>
> Will any fine-tuning be needed for the execution speed of the evolving
> source code analysis?
>
> Regards,
> Markus
>

  reply	other threads:[~2015-09-26 15:30 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-24 12:54 [PATCH] coccinelle: assign signed result to unsigned variable Andrzej Hajda
2015-09-24 15:51 ` SF Markus Elfring
2015-09-25 10:08   ` Andrzej Hajda
2015-09-25 15:51     ` SF Markus Elfring
2015-09-26  7:45     ` SF Markus Elfring
2015-09-26  9:07       ` Julia Lawall
2015-09-26  9:41         ` SF Markus Elfring
2015-09-26  9:45           ` Julia Lawall
2015-09-26  9:52             ` SF Markus Elfring
2015-09-26  9:55               ` Julia Lawall
2015-09-26 11:43                 ` SF Markus Elfring
2015-09-26 13:55                   ` Julia Lawall
2015-09-26 15:22                     ` SF Markus Elfring
2015-09-26 15:30                       ` Julia Lawall [this message]
2015-09-26 15:50                         ` SF Markus Elfring
2015-09-26 15:55                           ` Julia Lawall
2015-09-26 16:01                             ` SF Markus Elfring
2015-09-28 10:54         ` [PATCH v2] " Andrzej Hajda
2015-09-28 11:32           ` Julia Lawall
2015-09-28 11:59             ` Andrzej Hajda
2015-09-30 21:51               ` Julia Lawall
2015-09-28 12:07           ` SF Markus Elfring
2015-09-28 12:12             ` Andrzej Hajda
2015-09-28 12:20               ` SF Markus Elfring
2015-09-28 12:42                 ` [Cocci] " Julia Lawall
2015-09-28 12:55                   ` SF Markus Elfring
2015-09-28 13:13                     ` Julia Lawall
2015-09-28 13:53                       ` SF Markus Elfring
2015-09-28 15:07                         ` Julia Lawall
2015-10-03  7:09           ` Julia Lawall

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.10.1509261728140.2864@hadrien \
    --to=julia.lawall@lip6.fr \
    --cc=Gilles.Muller@lip6.fr \
    --cc=a.hajda@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=cocci@systeme.lip6.fr \
    --cc=elfring@users.sourceforge.net \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mmarek@suse.com \
    --cc=nicolas.palix@imag.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