From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965580AbcIWKhS (ORCPT ); Fri, 23 Sep 2016 06:37:18 -0400 Received: from bear.ext.ti.com ([198.47.19.11]:50598 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751972AbcIWKhQ (ORCPT ); Fri, 23 Sep 2016 06:37:16 -0400 Subject: Re: GPU-DRM-TILCDC: Less function calls in tilcdc_convert_slave_node() after error detection To: SF Markus Elfring References: <566ABCD9.1060404@users.sourceforge.net> <2f3f7ad7-16a0-1dfb-d073-0d993cd767ee@users.sourceforge.net> <0be7fee0-64f7-fa02-0337-51376677343e@users.sourceforge.net> CC: , David Airlie , Tomi Valkeinen , LKML , , Julia Lawall From: Jyri Sarha Message-ID: Date: Fri, 23 Sep 2016 13:37:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/23/16 10:36, SF Markus Elfring wrote: >> I think the "if (node)" in the of_node_put() is there on purpose, > > Yes, of course. > > Does such an implementation detail correspond to a general software design pattern? > Yes it does. For instance standard malloc()/free() implementation [1]. > >> because it potentially saves the caller one extra if()-statement > > This can occasionally happen. > > >> and keeps the caller code simpler. > > A special view on software simplicity can also lead to questionable intermediate > function implementation, can't it? > I don't really follow. But in any case I do not see anything questionable in the current tilcdc_convert_slave_node() implementation. > >> Keeping the goto labels in right order needs precision > > I can agree to this view. > > >> and can lead to subtle errors. > > The management of jump labels is just another software development challenge > as usual, isn't it? > Yes. But usually it pays of to avoid complexity when possible. > >> Sometimes there is no way to avoid that, > > How do you think about to clarify the constraints which you imagine a bit more? > If the the of_node_put() behaviour would not be specified with null pointer as parameter, there would be such a constraint. I am beginning to have a feeling that this discussion is not going anywhere. > >> but here there is. > > I disagree to this conclusion. > > Would you like to care a bit more for efficiency and software correctness > around the discussed exception handling? > No, I would not. I think we have reached the bottom of this discussion. For the moment I have more important tasks to do. Best regards, Jyri [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/free.html