Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2993432AbbEEQLi (ORCPT ); Tue, 5 May 2015 12:11:38 -0400 Received: from hofr.at ([212.69.189.236]:48809 "EHLO mail.hofr.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993492AbbEEQAl (ORCPT ); Tue, 5 May 2015 12:00:41 -0400 Date: Tue, 5 May 2015 18:00:35 +0200 From: Nicholas Mc Guire To: Julia Lawall Cc: 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 Message-ID: <20150505160035.GB9724@opentech.at> References: <1430820761-28122-1-git-send-email-hofrat@osadl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1843 Lines: 78 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; > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/