From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2120.oracle.com ([156.151.31.85]:42936 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387585AbfHVPFw (ORCPT ); Thu, 22 Aug 2019 11:05:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2019-08-05; bh=hCJpxpZbwe+4r6UC+Ss/Ot/m0j56MKhrB/YB91IriNE=; b=lwTrTVY+BVPdb+1B41cOn0v6MJG6gJPyModl4U3AwbRTv829kwrIPo30ZFdYNpqDyaJL NUopb0cnOfBQnp4oGg97ZN7tgOGCRcXuHt2dKZ+dySpZCtx35YYLkOs9vNbxACxDUZ0a Amwhdf16u1tTyDgFMiXc9XTDqy160uuESekPUKWHGGXYCJlrr9In6nl8Lpabbsrgv/1k 7Nvt9eoEO1xqF0xV5L7U5qMlPEE0zdoornZdxLNyf+jzTAJrgyyG97C313aDRgx94lZd OidL+YrLcGQz25JnWewRpVQlWlVALLfkTcI3IsF5DjyFBSPsh6lzdUVMQdwcFesdMPx3 7g== Date: Thu, 22 Aug 2019 18:05:29 +0300 From: Dan Carpenter Subject: Re: noreturn attribute doesn't work in smatch Message-ID: <20190822150528.GL3964@kadam> References: <20190815005328.GA8004@movementarian.org> <20190815111237.GA20100@movementarian.org> <20190822132800.GJ4451@kadam> <20190822134603.GB9904@movementarian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190822134603.GB9904@movementarian.org> Sender: smatch-owner@vger.kernel.org List-ID: To: John Levon Cc: smatch@vger.kernel.org, linux-sparse@vger.kernel.org, yuri.pankov@nexenta.com On Thu, Aug 22, 2019 at 02:46:03PM +0100, John Levon wrote: > On Thu, Aug 22, 2019 at 04:30:34PM +0300, Dan Carpenter wrote: > > The code to handle that is really ancient. You need to do: > > ./smatch --info test.c | tee warns.txt > > grep no_return_funcs warns.txt || echo FAIL > > ./smatch_scripts/gen_no_return_funcs.sh warns.txt -p=levon > > mv levon.no_return_funcs smatch_data/ > > > > Then pass -p=levon to smatch on the next run. > > OK, thanks. That doesn't match too well with the way we use smatch, but > this is much less of a big deal (I only needed to annotate this in a > couple of places). It should be the the DB, right? Would that work for you? It's sort of an awkward thing because I publish the list of no return functions used in the kernel, but I don't publish the DB. So I probably have to keep both methods... regards, dan carpenter