From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752810AbbIZPWv (ORCPT <rfc822;w@1wt.eu>);
	Sat, 26 Sep 2015 11:22:51 -0400
Received: from mout.web.de ([212.227.17.11]:56161 "EHLO mout.web.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751386AbbIZPWt (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 26 Sep 2015 11:22:49 -0400
Subject: Re: [PATCH] coccinelle: assign signed result to unsigned variable
To: Julia Lawall <julia.lawall@lip6.fr>
References: <1443099286-16559-1-git-send-email-a.hajda@samsung.com>
 <56041BE5.5010005@users.sourceforge.net> <56051D2B.5040802@samsung.com>
 <56064D0B.8060907@users.sourceforge.net>
 <alpine.DEB.2.10.1509261106040.2737@hadrien>
 <56066866.1060602@users.sourceforge.net>
 <alpine.DEB.2.10.1509261144270.2737@hadrien>
 <56066AD4.9060306@users.sourceforge.net>
 <alpine.DEB.2.10.1509261154500.2737@hadrien>
 <560684F3.9090700@users.sourceforge.net>
 <alpine.DEB.2.10.1509261554100.2717@hadrien>
Cc: 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
From: SF Markus Elfring <elfring@users.sourceforge.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <5606B837.7030608@users.sourceforge.net>
Date: Sat, 26 Sep 2015 17:22:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.10.1509261554100.2717@hadrien>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:jaGdtyOVhZhqdmznZmpAmyGSwnD10Uz1beLS08UZjWjus9Xj5zc
 w2QuFTQyMI+T3BbpMfWxAU4ixmuwAHPndLphgfhu//4Ouxuf5aZls4p9JWNU5IK0vv2bjDn
 Yh/XAjgISgUcyYcZneHtwtGiAzEIRCNXhIdTgqMJ3mppgTz1SEqU1ErxYOc+zch7bzAdIDx
 13vB0kYfRHDN2tWEbxqdA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:nD34ppZbHSM=:obeLFqqI4zTXMKECy7Bvss
 RoAdKDCZ3Fo11hE9HrjpaEddpCtafUhyt95211k3P+H4Y/ZMdgzn8tHF0jYexnQi5eeqkK6zF
 IJ+/HGDm9r4nSiYmf7Q0xfC++WNmydvUFLkWTl2fg6Uozb1P/jvWUoXWpwhDvT1onLaSoHf+N
 jG0LJqunAl4Sj3o/DUT07Cua9+R77eRlydxqrJTHqZlv5JeY4/6hGg3o4t2xCE9TZAAJ54R84
 1HQAQSFf7xbnhoFpiG6l2ZMD8Wpvkojkp9Q2+Lis8LKxx4CPM4TWotsGTts+sJ9l+NJ4FCiGN
 rjYNB1bGOIUpeXiTbJochqD5FlrUIQnp3J/udPsQOj0OTYhwSuF9tzbXUri1QyXZ+x3j0Po34
 E8IJIJb9pF/GfDgbDsWv7/9nRQTjJQFXHkHta6dTJwDfV5Xms+8d++pkkMNVobmbHozJfWWwW
 1APTtGxhgMZUjR2Dwt7nGD/xXwiP7pnZVlPDP7OViTtOXfvoK/b1X1gr/LqvP8q279fOmwi/H
 WSy147Wbp7hWfyGFbzMEMoqjf9lvfgdM62e63hcGM2+QvJyVG3ypvk6WUV9/Huz/jmDAcSHyk
 fVwin10Ugt7qWPNahBuJP+8AyeWtkgwXScG6HhX6n+W70aOd7VM4/xLGnUdtnyd3sL0qLARha
 JQsCN0h1g3i9vhh1OG38JiLvYFfGGqwf6X1NF/7LXcNgaxLmjTva67GKIZ4ZtBxxD3B8XWUFJ
 WApsPJD71AkceuuGsdgOsD+CqZiPRNg7EGlXXg==
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> 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.


>> 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.


>> 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?

* 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