Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp879010imj; Fri, 15 Feb 2019 08:16:55 -0800 (PST) X-Google-Smtp-Source: AHgI3IbJ21zaw28nKtbYd1/fZcK+Do1a5bJaJkh+47xWH3XVcMcheM/1YKbC1Uve7+3Wn+l85M/Y X-Received: by 2002:a17:902:28aa:: with SMTP id f39mr11079446plb.297.1550247415793; Fri, 15 Feb 2019 08:16:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550247415; cv=none; d=google.com; s=arc-20160816; b=P+SAE1SphqNQE0SX4b+Rhqi9DXv62kqMatyHuO7sMhMudbdzEE9OmGS4UQ0hRAqDxo T7J0XKjz2lpPYaIUtywQx9P026p4oxSGFVCYBwepLB8xCkR/BbwozF0PaouxF74g/d0q KgIYkSSvKTt6qtqUkPk/qv1wKCpvxQ9juwOTnmwg955wZ7Ftb4cq19f473sXEWdT/+LE UUwwt3BiaWtQw/N6KO5umdvcnRu73Lqb1Ffk/QHwPokG6qZIxGJg/jA7xTH16LZz1u0h RA2ibxWb3wrCyrNavQu0/SDUGjb8oafKCOf5ShW1kNRRWLPWokDg0Eq/DE2zjx1F4VQ/ j89g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=P4Kb9fMpxn+AUyLWmZT1sn/3X9SX/1VLJjMjJa/rStE=; b=y8hJxJzfJWfBYfKhEM2pIgktT5p3LOB40pGl2jKoS4/H25ZpmpNzQWAIM5pXL3imUn L6oohhN82YZB2ijD8s8bwHGFkmyMES0SsE/XNmlD/xt+S0GqcEpt/7p6NuTZWmecp84N c+/fpkXtKoj8c6FkhflFDnASKoQghjhZ6KYkn53lMR1U90Fx3LKU5TfWKt+lk2gQBfJx BVoDwwC8DWnZ6D51qB3tnu7yrG4W5rlUGL7VongCVheKNxhN+iokS5tUcKS3GtVcGRU8 GQqNJXJl63KugLGpl7H161slpFL/3V6nCLIef6GaVZKIj67FVjL0fNk+mlD87SzzLa2M hlRA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 102si5801645plb.176.2019.02.15.08.16.39; Fri, 15 Feb 2019 08:16:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394904AbfBONYp (ORCPT + 99 others); Fri, 15 Feb 2019 08:24:45 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:28438 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726026AbfBONYo (ORCPT ); Fri, 15 Feb 2019 08:24:44 -0500 X-IronPort-AV: E=Sophos;i="5.58,372,1544482800"; d="scan'208";a="369582185" Received: from vaio-julia.rsr.lip6.fr ([132.227.76.33]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2019 14:24:40 +0100 Date: Fri, 15 Feb 2019 14:24:40 +0100 (CET) From: Julia Lawall X-X-Sender: jll@hadrien To: Markus Elfring cc: Wen Yang , Gilles Muller , Nicolas Palix , Michal Marek , Yi Wang , Masahiro Yamada , Wen Yang , Cheng Shengyu , cocci@systeme.lip6.fr, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [v5] Coccinelle: semantic code search for missing put_device() In-Reply-To: Message-ID: References: <1550217319-40418-1-git-send-email-wen.yang99@zte.com.cn> <94e4b3e6-87a4-aea2-dfef-44d308f0fb4f@web.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-453697585-1550237080=:3617" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --8323329-453697585-1550237080=:3617 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Fri, 15 Feb 2019, Markus Elfring wrote: > >>> +id = of_find_device_by_node@p1(x) > … > >>> +if (id == NULL || ...) { ... return ...; } > >>> +... when != put_device(&id->dev) > >> … > >>> + when != if (id) { ... put_device(&id->dev) ... } > >> … > >> > >> I would interpret this SmPL code in the way that the if statement > >> for the pointer check is “optional” in this line. > >> Is it an extra and redundant SmPL specification when the reference > >> release function could eventually be found just anywhere within > >> an implementation? > > > > The proposed when code is correct. > > I agree that this SmPL code can work in the way it was designed. > > > > It is not redundant, because it checks for a particular control-flow pattern. > > It took another moment until I dared to express a different software > development opinion also on this implementation detail. > > Does the first SmPL when specification include the case that a call > of the function “put_device” can occur within a branch of an if statement? It does include that, but there is another execution path where the put device is not present. But given the test in the if in the when code, on that execution path id is NULL, an so there is no need to put it. julia --8323329-453697585-1550237080=:3617--