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 S1752285AbbIZJzv (ORCPT <rfc822;w@1wt.eu>);
	Sat, 26 Sep 2015 05:55:51 -0400
Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:59383
	"EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with ESMTP id S1752019AbbIZJzu (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 26 Sep 2015 05:55:50 -0400
X-IronPort-AV: E=Sophos;i="5.17,591,1437429600"; 
   d="scan'208";a="148657016"
Date: Sat, 26 Sep 2015 11:55:46 +0200 (CEST)
From: Julia Lawall <julia.lawall@lip6.fr>
X-X-Sender: jll@hadrien
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
In-Reply-To: <56066AD4.9060306@users.sourceforge.net>
Message-ID: <alpine.DEB.2.10.1509261154500.2737@hadrien>
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>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



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

> > Your approach finds a function definition.
>
> Yes. - I assumed that it might also be relevant.
>
>
>
> > My approach works on the call directly, using whatever type information is available.
>
> 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.  e will thus match the entire expression.  e is declared to have
type t (where t is in practice signed int or whatever one wants to check
for).

julia