From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932249AbcLLHjq (ORCPT ); Mon, 12 Dec 2016 02:39:46 -0500 Received: from zed.grinta.net ([109.74.203.128]:53402 "EHLO zed.grinta.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751375AbcLLHjo (ORCPT ); Mon, 12 Dec 2016 02:39:44 -0500 Subject: Re: [media] bt8xx: One function call less in bttv_input_init() after error detection To: SF Markus Elfring References: <5560ffc2-e17d-5750-24e5-3150aba5d8aa@grinta.net> Cc: linux-media@vger.kernel.org, Alexey Khoroshilov , Hans Verkuil , Mauro Carvalho Chehab , LKML , kernel-janitors@vger.kernel.org From: Daniele Nicolodi Message-ID: <581046dd-0a4a-acea-a6a8-8d2469594881@grinta.net> Date: Mon, 12 Dec 2016 00:39:39 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/12/16 00:33, SF Markus Elfring wrote: >>> I would prefer a safer coding style for the corresponding >>> exception handling. >> >> Can you please point out what is wrong in the current code > > Is it useful to reconsider the software situation that another memory > allocation is attempted when it could be determined that a previous one > failed already? No. > Are two successful allocations finally needed to achieve the desired task? Yes. >> and how the changes you propose fix the problem? > > I suggest to check return values immediately after each function call. > An error situation can be detected earlier then and only the required > clean-up functionality will be executed at the end. Which improvement does this bring? >> No one has expressed acceptance for the kind of change you propose with >> this patch, or to previous patches you proposed changing similar constructs. > > I got a mixed impression from the acceptance statistics about my > published patches. Have you proposed a similar patch that was accepted? I don't find record of it, but I may be wrong. >> The fact that you propose over and over again a class of changes that >> has been already vocally rejected would suggest otherwise. > > I dare to propose another look at results from source code search patterns. Why? Cheers, Daniele