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 S1752746AbbIZPue (ORCPT <rfc822;w@1wt.eu>);
	Sat, 26 Sep 2015 11:50:34 -0400
Received: from mout.web.de ([212.227.15.4]:50875 "EHLO mout.web.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751639AbbIZPuc (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 26 Sep 2015 11:50:32 -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>
 <5606B837.7030608@users.sourceforge.net>
 <alpine.DEB.2.10.1509261728140.2864@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: <5606BEBC.4010305@users.sourceforge.net>
Date: Sat, 26 Sep 2015 17:50:20 +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.1509261728140.2864@hadrien>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:Uzv3PpKBjrh5OAe1AgxboQQogmn+XCjRZz7Ky6SFKA0y5vkUToz
 L4biKT1csTVXYXjeZy2ScF5YHLSfosPPAsiR/p6FARffbqKOzcuoI36wsMsFwMg6RNpM7jH
 LCzOrjsAp1LTqvuipSmWYdumfPYxY+Bwl++69xJruvMaOMEmUWLPO2qBIXievtRS/BNbzpC
 WUMkdkiSqaLOJIQzCi6nA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:WRidG5UyG+o=:FQFwg09OqkDiUELQNiLWGh
 dNFCAnUKWnHOBVKJnv0y+hnn/bk8iAs2Fjs0siZgfNSPistY73LtDTuQNb0nf1U8r1WCoJxuu
 jirxNGZm0VbZgjM+OFa2Z3AYstXZwQ0n3+f5d9GLlQJVHHvhgGJN7gR6Q2Y6OUu4pWwLDphtE
 5H9aOFbFyRPIvtNku6PFLG7mVzezNthdgoo8xWPZeU+jTXpmiVJS/MC1y4sLDC4ijvEZx+2wj
 AD/3m2sz7wf4M8tMXdtBnjCy/bgq0HVqVQTFjCvL9pNkpNmzXo9MvREaFv78CW0S+ln7LsIH1
 YdvwhxynfZtV4q+dzdCpCsAIEMYcO2CpBYkKvJZxPmKxwYnS54o5JkLRK3Zpq3xEoXlZbKV6I
 STS/PyrSEfQnOYNzmMTgzBuEjek60fTidIcELGf/tIoPFxdi/epfss05bzDDnX6CQxCJE4VUc
 G+rC7y6y2ZlWED7ki2kZv6LOVxGzQpvCMrMUhiNsU9UD7V5F0e0fnmMnG3WfD+THCa0T1amN9
 Y2A+OXVTE3/ZblwvVDz5zCub5O4eIHWIJAJq6Ax7DlPoHjnvffK+T4P4Z6EAj9w9FjMb5SfwZ
 5Ypi6Eh9FB4vR96LdPZRzr/8K5vXS/bARNkQ8tIiy0Jy7bzYEfeBPAEXVg79XZaMzdTGjr1hE
 IZU5dELV7zyS9oKkQYUxV0gOst15EmbtYQu3lspKvNCC5wV8sm6of0Vb4ktGXzUFLbBophBrU
 cizHCD/czjE5p2DdymJgq+cRijc+S7nHGzuIEg==
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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

I would consider the reuse of the parameter "--recursive-includes" then
so that the most function signatures will be available.
This has got some consequences on the execution speed and configuration
for the source code analysis.

Are there any risks to include too many functions?

Regards,
Markus