From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946019AbbEEVZy (ORCPT ); Tue, 5 May 2015 17:25:54 -0400 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:46703 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1945943AbbEEVZx (ORCPT ); Tue, 5 May 2015 17:25:53 -0400 X-IronPort-AV: E=Sophos;i="5.13,375,1427752800"; d="scan'208";a="139119683" Date: Tue, 5 May 2015 23:24:55 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Nicholas Mc Guire cc: Julia Lawall , Nicholas Mc Guire , Gilles Muller , Nicolas Palix , Michal Marek , cocci@systeme.lip6.fr, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC] Coccinelle: Check for return not matching function signature In-Reply-To: <20150505160035.GB9724@opentech.at> Message-ID: References: <1430820761-28122-1-git-send-email-hofrat@osadl.org> <20150505160035.GB9724@opentech.at> 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: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 May 2015, Nicholas Mc Guire wrote: > On Tue, 05 May 2015, Julia Lawall wrote: > > > > +@match@ > > > +identifier f,ret; > > > +position p; > > > +type T1,T2; > > > +@@ > > > + > > > +T1 f(...) { > > > + T2 ret; > > > +<+... > > > +* return@p ret > > > +; > > > +...+> > > > +} > > > > Given the number of results, it may seem surprising, but I think that you > > are actually missing a lot of results. Becaue you require that ret be the > > first variable that is declared in the function. Also, you require that > > ret be an identifier. If you want to keep the restriction about being an > > identifier, you could put: > > > > @match exists@ > > type T1,T2; > > idexpression T2 ret; I was think ing that you don't want expression in general, because for all contansts that will give you int. You can of course put return C; for constant metavariable C in the disjunction to avoid that possibility. julia > > identifier f; > > @@ > > > > T1 f(...) { > > <+... > > return@p ret; > > ...+> > > } > > > > this is depressing - I now like by wrong solution even more ... > unfortunately you are right - I missed most - its now at 25146 > > > If you don't care about the identifier constraint, then you can just put > > T2 ret. Note also the addition of exists. There is a problem if only one > > path has this property. Another thing you can do is the following: > > > > @match exists@ > > type T1,T2; > idexpression T1 ok; > > idexpression T2 ret; > > identifier f; > position p; > > @@ > > > > T1 f(...) { > > <+... > > ( > > return ok; > > | > > return@p ret; > > ) > > ...+> > > } > > > > Then Coccinelle will find the cases where the types are wrong, rather than > > requiring a test in python. > > > > (I haven't tested any of this) > > also works - I had naively expected this to be faster - but it does not > seem to be. > > will check results did not expect 10% of the kernel functions > to have missmatching return types in atleast one of their paths. > > thx! > hofrat >