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 S1752934AbbIZQBa (ORCPT <rfc822;w@1wt.eu>);
	Sat, 26 Sep 2015 12:01:30 -0400
Received: from mout.web.de ([212.227.17.12]:52423 "EHLO mout.web.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751921AbbIZQB2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 26 Sep 2015 12:01:28 -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>
 <5606BEBC.4010305@users.sourceforge.net>
 <alpine.DEB.2.10.1509261754350.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>
Message-ID: <5606C14B.2080400@users.sourceforge.net>
Date: Sat, 26 Sep 2015 18:01:15 +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.1509261754350.2864@hadrien>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:CUVXuKN3gQY/sXPtMt7vdJ3WzY25I3BK2eE+a9WiwNzgDpj1vsb
 WAb3m+iSJl3PhD4bFLL7VQSIOaTQiZrK6VtR23KS7OhUUDbr/UrWXo5yoXJtHpjSXHfE0I/
 7JdRKFDzunWfJOJd2orLs+XLkkUgpinjAmipwwzD7j0kOAriCUuVenNZ11b4BdK+/1YD7E9
 oR6TwJy3e175NGpd0k9tA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:wgg45dSr8jI=:P1fY89rEbwdU+uitiVBtJj
 BiuXWx0AnEf4XlG4FGB2Qya7MqYri02wT+MZllzWqNtRrXNoeNbjyFXW+VRHARYVLPxeii37h
 0m/j5VMXAit3UTnHppa+Pt0N9F34pJzgzhI8uvmY4m+AwO9nlLevHe+yozGMAfvxqhPe0cGZg
 Hl7KLrJjYdZCH5Rx5guDtWt3nBDasrntIhP9rxwfMdGdOea+bJXb9UMLyy/16wS2Tfn6DoqY0
 gMmJb5jARZybnV3VLiN7NkqzByg6sLI/JGo20Qw8B8y+Hn5wQvyuQShsyMnQlJsAlXnatGcNn
 XKJBNZqzgVTYoeQ6p8SWGyT0xz0GOwuF/k6BO0poz2kiSqajh/NDxnAzLTrt0fAbF5yveY0Ys
 RSv0w3ZAvjf7SC2tr+TJC004JpyiGc2zRuRp/juxtU+hNPlm1fhUiFcBZ2QPa+bXB/53q5EC9
 ShHjZbc/WZkMsrYxGpVn91xmPTrcElFEhk9wBkUs9VsJaO1allQBtFpqjEpc58WsCDKpIt6QV
 MBauZ5v/jxwyt28dE3y9Pg1Y93hElJDCvI5zRt0paaCJtN1vj5FzmzM92CaDEuwRRqO5dUU8b
 Q2F3w4nJxGzQz79WdjaJH1uIGYA65aqEGfCxF6Hvi+Q53T5kV51oUjT7gDnuy+PBAj6CNTI7G
 B7Y3/l+YVhXdDga8q+Cdg1bSbTTtDJ8nCqR3aZp0tw05gX7Dq38xIhZnhDMMQrRD+oNCPsrS7
 yu1CbTjKz9rqqeDm/mOU+5rDGjknGxsBir4vnQ==
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>> Are there any risks to include too many functions?
> 
> Maybe if there are conflicting definitions of the function with different
> return types.  This is probably not a big deal in practice.

Are there any more concerns around the handling of conditional source code
analysis for Linux subsystems?

Regards,
Markus