From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751559AbbBPVYl (ORCPT ); Mon, 16 Feb 2015 16:24:41 -0500 Received: from mout.gmx.net ([212.227.15.18]:53637 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751300AbbBPVYj (ORCPT ); Mon, 16 Feb 2015 16:24:39 -0500 Message-ID: <54E2600F.9060502@gmx.de> Date: Mon, 16 Feb 2015 22:24:31 +0100 From: Helge Deller User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Nicholas Mc Guire , "James E.J. Bottomley" CC: Dan Carpenter , linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: RFC arch/sh/kernel/traps_64.c - unclear if/else construct (hpux compat layer) References: <20150203093758.GA27963@opentech.at> In-Reply-To: <20150203093758.GA27963@opentech.at> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:F9sTY1WnmAecvNCFVIDv30GB7CeR/DbdTA35vLGFKgex5v9MNGu r7Rx3VCz26XXg4B4LmCvuSu9IaxQu4Oc6T5qwXuehCHSi99IiBxW4IfvPwAjrTa1CcazWkF a/8y1l3pYvFXbESAx/yZBKd49p/1e+B6wvnVpF1OdAqsfkKht6gu3DTN63pWV2UplFNU+fJ uKB6NcQ0tsUQif9m1xsKg== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Nicholas, On 03.02.2015 10:37, Nicholas Mc Guire wrote: > scanning for if STATEMENT else STATEMENT triggered here - and it does look > like it needs a fix-up or at least some comments. > > int hpux_sysfs(int opcode, unsigned long arg1, unsigned long arg2) > { > int fstype; > ... > /* String could be altered by userspace after strlen_user() */ > fsname[len - 1] = '\0'; > > printk(KERN_DEBUG "that is '%s' as (char *)\n", fsname); > if ( !strcmp(fsname, "hfs") ) { > fstype = 0; > } else { > fstype = 0; > } > > kfree(fsname); > > printk(KERN_DEBUG "returning fstype=%d\n", fstype); > return fstype; /* something other than default */ > > > The if-else here has no effect and the printk will not convey any information > as its always fstype==0, finally the return statement comment indicates that it > should not be the default... > > Can't come up with a reasonable cleanup patch here - but this looks like it > needs a review. The hpux code is broken anyway. I'm going to remove it from the tree. Thanks! Helge