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 S1752789AbbIZLoJ (ORCPT <rfc822;w@1wt.eu>);
	Sat, 26 Sep 2015 07:44:09 -0400
Received: from mout.web.de ([212.227.17.11]:52535 "EHLO mout.web.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752708AbbIZLoH (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 26 Sep 2015 07:44:07 -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>
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: <560684F3.9090700@users.sourceforge.net>
Date: Sat, 26 Sep 2015 13:43:47 +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.1509261154500.2737@hadrien>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:LVSCFkSQzjIlzUWX7wmbxQuNRKehv+C9Uc4m1EjjXvakvMCRwNN
 XvOl9XLdrcNfxkVweOceg34JdiHe88TCp0eGyOUUO+NYVd37ZazQ3GuBE4JvmlWu3of/UMA
 kZ0sUhbqrwercRJhiYbvLz6l0v5zPuCFuF7otolTxVtU8XKQHLJvz6HhY2f9AkaRqtTp1qJ
 WSPDGMrqpocX8TycO2/Zg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:x8EbaBoAwjQ=:fcxROca/zq9++eTRFPdtiJ
 WU1Ptwdu6JUeugcuILJrHig+MIkBSUN7flVq5s411aWHUya1e2Ar+3pE247k4u69fYnBm+bx0
 s7pdMBWmklvwCmP7ZVbqgHUx3YyYaCFGPKfteVZcYC7A9aZbuEzlHAc77/wlzsKVWUxkE4MRX
 wH4r7YfGXby4qwiB0NwOOfzuZ2UGVshV3wXq4qZpDq1Sf6u+9PbwxIQx3IJ8p5aLZT20j8lXE
 jxM8O03H0iaWmI2TEy01D+lfOhpkjMhQRPr0QfvMNDxwXb4HggfbAUWwexWfFAx71niLYdOQt
 LvXRFDmpLotfr2R8oErtEWRuqzL7CJUm4JeVVVMgNlUDW07t5zgvvRJfp13jTfkKF6QShoO3Y
 3mVdisdsjMF6XESTwKjsVvknZaB2x1Bv4LgSyOrC1XEqgIgboVu9bbsFmlVHJzrzmlAj7POX+
 3ibg98na/EVDDXg+Ou59P31HhgXs8h1Izn4LF47KbzdhAa/RMAg2t8X1W5+hfwwI7RCu96KL8
 0eMcprXKJIHdt4ejq753IRaHqM85q7jjm5aVblYhlgCNBm7L1RYE8CYG8AXF7n6nJN5hNua9U
 JUlSHaoozuCjxXB8QegnKJSZqkZa/hHKF/3T+LkcrWj9VWAdDqJF8Gr4cyJAfveE0vIQpGdAt
 /SB4FrIkJHeJmAIBhlA/ZNE4dL/52uHE0CpiH8e9dz4ZzHnEV+kMVZKU+zo9qwT1o7tFu4k0C
 WQNBhUw45P11on+/lF+B7FpyAWxG+ED3AOPRUw==
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>> The connection between the SmPL specification "f(...)@e" and the desired return type
>> was not obvious for me so far.
> 
> The nearest enclosing expression of the ) is the whole function call itself.

Thanks for your explanation.

Now I guess that the enclosing context is a particular function implementation
where specific calls are performed, isn't it?


> e will thus match the entire expression.  e is declared to have type t

Did you omit this detail in your suggestion a moment ago?


> (where t is in practice signed int or whatever one wants to check for).

How do you think about reuse another data type enumeration there?


How would you like to manage names for functions which are not defined
in the current source file?

Regards,
Markus