Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp2650743pxb; Tue, 24 Aug 2021 04:29:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzaty2FgjZYH0bgTciSYvx3Cw2QH4/HO51gadZD0bmFoy47d2/Lv5pgdSmNKrYyhBxvtTlP X-Received: by 2002:a17:907:2123:: with SMTP id qo3mr40494247ejb.277.1629804593538; Tue, 24 Aug 2021 04:29:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629804593; cv=none; d=google.com; s=arc-20160816; b=fakrME1Dn//8MQGcOtdFFqpNFzkFGe381GnNpQ9tIZVMpMRSw8993yaOZ3qX2KdV5L tQ1/mWycdzvs357VgfKl5otHs6gGkR1gUy4Slu48seDB/wurdO4x+QwzjZsqpbLL21UW DE7yvwzyeMyKW57RNI+MuJiqxmjrxSKyxavYTaxIyVKrC3SNfkmUgYnMIa8i96Z0MDm4 VhvUik4jof3vSrPVWWYzYR9UzGoLnVNubZgFM/ONqlO1wGR9hSuIJau/D8H3/8Y/I8zc N96Cv5hsklugnfWY3pD1RnSrt+ZYMi5c+G3VHBeAUzn4tVv1tVXipCm0SRdPJnc0CIEt 8pag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=csZdA38ecZk4uzGs0BOWcnl0I/SkMeploJ4X7WtB8Yg=; b=GSucMg5ZT3lhv9sX22fIYKOgubcM48A4X3yf7r0gi+xp8w34CbA8q+enJwJX6e+dE8 penxZcvsN7IPIwWNEn25Z5VoX+qqINnyOHxCe3oZCjIQl01oGZxEfzjTIX4N/2dhv7/Z tU8H/AS8Mj3EhB7UjsxWJX3q1LkRuoZ+U/eB4liu+iZFLNMWvlsHBmxN76F4ebivkZfW FRLYqknLIZGjVmiF3pNCipqx3RLKyjRoQ51S2y+AMQixBErrmn9U4ENARqkNd+CIQAuJ GOFHs8E6IJtdvx1h2Ua5pXhsZcJpr7O4CQRyuCrSSIKGf2EfvYYEGNc7JeP+8sgPj1Oy CR/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aztByu6W; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y21si182223edv.223.2021.08.24.04.29.29; Tue, 24 Aug 2021 04:29:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aztByu6W; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235125AbhHXL3A (ORCPT + 99 others); Tue, 24 Aug 2021 07:29:00 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:46547 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235509AbhHXL25 (ORCPT ); Tue, 24 Aug 2021 07:28:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629804493; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=csZdA38ecZk4uzGs0BOWcnl0I/SkMeploJ4X7WtB8Yg=; b=aztByu6WayThQN53bp0LtYjSVKzhL8s5DffGpULa8175eJT+vQFitqw9sYReGKefpKToXp OGga6MhKf1AsXC0Iu9wjjiFzhQ0qrj32iCnu5+Gyt2Ft9MVJNUU7tPCwUSxIc5JKPoKllF ifG3VG8W61MNWPvKZLFymAR9Qrq0Ud0= Received: from mail-yb1-f200.google.com (mail-yb1-f200.google.com [209.85.219.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-377-GB-jpdj2N_iGOkt_TVPVkQ-1; Tue, 24 Aug 2021 07:28:11 -0400 X-MC-Unique: GB-jpdj2N_iGOkt_TVPVkQ-1 Received: by mail-yb1-f200.google.com with SMTP id x5-20020a0569020505b0290592c25b8c59so19467082ybs.18 for ; Tue, 24 Aug 2021 04:28:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=csZdA38ecZk4uzGs0BOWcnl0I/SkMeploJ4X7WtB8Yg=; b=PfxY7lwu1Fm62nh7kJlxRrr6TsNzksuQS39GQyzSywFWJWlHHQ+yg3rgsjlGhe87TJ NFkmbg49rBnamTX2f0FAhCHMZSrBCM/imBPIMl/RGFUbsf9/7YyAK/yfVDSsqKRypY42 Z/I/e2L3H6WTk45LczkPt4EOht9GR5FF9op998o1Vkq4H7xq/Sk2ZY/RCIoy70WeOgUd XtHlxgzJDG/fiLbcohpE3bay/RqnKx6ly5V+TaUeptfeVoWUkpGL4fCkQLWWa7SsMi4W G1Sd+hWztA58jANpIMvhIeCLIMqMt2tct3w+mmVIRUc5SIZhD9r6WghXAsaa2GhHekQz KtlQ== X-Gm-Message-State: AOAM532od/rUY5jeu/SnY2Xei+wO3422Me16kZR1I13CO5wGH48jpY+I MTwnnF2eQDsmsFGfBNKuj/ZwJC6/W7sQUa1ksX9T1Ni6UNoDJSjjbXVjeGHUjkc0qvRVya5hZxP c6hN3vt03QgLYBXOB/rSSQxIaOw2MT0H3m/86d8Wp X-Received: by 2002:a25:6b50:: with SMTP id o16mr24086392ybm.400.1629804491445; Tue, 24 Aug 2021 04:28:11 -0700 (PDT) X-Received: by 2002:a25:6b50:: with SMTP id o16mr24086370ybm.400.1629804491221; Tue, 24 Aug 2021 04:28:11 -0700 (PDT) MIME-Version: 1.0 References: <20210824022247.GA22908@raspberrypi> In-Reply-To: <20210824022247.GA22908@raspberrypi> From: Ondrej Mosnacek Date: Tue, 24 Aug 2021 13:27:59 +0200 Message-ID: Subject: Re: [PATCH] selinux: remove duplicated initialization of 'i' for clean-up To: Austin Kim Cc: Paul Moore , Stephen Smalley , Eric Paris , SElinux list , Linux kernel mailing list , kernel-team@lge.com, austin.kim@lge.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Austin, On Tue, Aug 24, 2021 at 4:23 AM Austin Kim wrote: > > From: Austin Kim > > The local variable 'i' is used to be incremented inside while loop > within sidtab_convert_tree(). Before while loop, 'i' is set to 0 > inside if/else statement. > > Since there is no 'goto' statement within sidtab_convert_tree(), > it had better initialize 'i' as 0 once before if/else statement. > > Signed-off-by: Austin Kim > --- > security/selinux/ss/sidtab.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/security/selinux/ss/sidtab.c b/security/selinux/ss/sidtab.c > index 656d50b09f76..301620de63d3 100644 > --- a/security/selinux/ss/sidtab.c > +++ b/security/selinux/ss/sidtab.c > @@ -374,7 +374,7 @@ static int sidtab_convert_tree(union sidtab_entry_inner *edst, > struct sidtab_convert_params *convert) > { > int rc; > - u32 i; > + u32 i = 0; > > if (level != 0) { > if (!edst->ptr_inner) { > @@ -383,7 +383,6 @@ static int sidtab_convert_tree(union sidtab_entry_inner *edst, > if (!edst->ptr_inner) > return -ENOMEM; > } > - i = 0; > while (i < SIDTAB_INNER_ENTRIES && *pos < count) { I must say I prefer the original version more, because it makes it clear when you look at the loop that it starts at 0. Once you move the initialization to the declaration section, readers will have to scan the code upwards to find it out. As is, it's also less prone to error if e.g. someone adds another loop before the existing ones and reuses the variable. In case anyone is wondering why I didn't make these for loops when I wrote this code: Since the loop condition a little more than the usual "for(i = 0; i < n; i++)" pattern, my intention was to emphasize that this is not a "regular" for loop and that readers should read the loop carefully to not miss something. But perhaps that's not a good reason and they would look more natural as for loops. If others think a for loop would look better here, I'd be OK with a patch that makes these into for loops instead. > rc = sidtab_convert_tree(&edst->ptr_inner->entries[i], > &esrc->ptr_inner->entries[i], > @@ -400,7 +399,6 @@ static int sidtab_convert_tree(union sidtab_entry_inner *edst, > if (!edst->ptr_leaf) > return -ENOMEM; > } > - i = 0; > while (i < SIDTAB_LEAF_ENTRIES && *pos < count) { > rc = convert->func(&esrc->ptr_leaf->entries[i].context, > &edst->ptr_leaf->entries[i].context, > -- > 2.20.1 > -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.