From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jHK6T-0004Aq-4o for mharc-grub-devel@gnu.org; Thu, 26 Mar 2020 00:26:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38907) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jHK6P-0004Ab-Ju for grub-devel@gnu.org; Thu, 26 Mar 2020 00:26:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jHK6M-0001OB-W4 for grub-devel@gnu.org; Thu, 26 Mar 2020 00:26:44 -0400 Received: from m4a0072g.houston.softwaregrp.com ([15.124.2.130]:53471) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jHK6M-0001Dp-OO for grub-devel@gnu.org; Thu, 26 Mar 2020 00:26:42 -0400 Received: FROM m4a0072g.houston.softwaregrp.com (15.120.17.146) BY m4a0072g.houston.softwaregrp.com WITH ESMTP; Thu, 26 Mar 2020 04:25:21 +0000 Received: from M4W0334.microfocus.com (2002:f78:1192::f78:1192) by M4W0334.microfocus.com (2002:f78:1192::f78:1192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 26 Mar 2020 04:25:06 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (15.124.8.10) by M4W0334.microfocus.com (15.120.17.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10 via Frontend Transport; Thu, 26 Mar 2020 04:25:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M+lce/pn//33Z9CJ5khfL9jGPPWNoCIsx6zgF2VXGEY4IIjH0poMw1tC80kq6oJDczjiVV18rEXf6z2Y6SL6fE6Yje482e4PVuDB2k11xOP3Wkav0+b69w4QRqjrd9apPwOR17UGyWBOXYNu9qPrmfWoueECG3/3BH9Q48vHSWeiQ1FKYx7+j/0+t30jsAoaKZLgS67HOh7ohyEKUwMNZsoWbTWv1x9eRT+OVwCktpnc6J0ME5dqm+NolLxTJWQ5uWUeU99iOREwk1Rf7z8KziAGgdyXo4QVyyhM7zC/+lad9FfP5xI1jhlSbTqczYyKuercIv4iSUVnmyk84bgRXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9CKBNnNynvabliC42L73cpRmlMqnjqvXLYW6JAqCyQs=; b=KjCRmnbty8peWkhkq9owJyS1RZTkshimk/n7lCMDJzLegluRrApKmgKKWu+kKT2u3dTOH8yXphuMdjJ7/p14y94dYeNAh6MVXyYKByLnYbMpnaL9W+KZMvrGozwqnZiYIwg9HeuKLzgnaslFS+MpKnnkdyhj2TVL07N81S30RjAVlaV+r1NFJrr/hjR+2coMOjVv1wX/aqd5bJZvncGnnh//rT7IaHhmaRlnKt/5WEqXJSU59JspLpNOEHEfhVtx1Dl3o2UjGuij1YOPSYvTXKjg5q2tf7qtq4IwDTFkPZJLjHg9/TWZzLoMRJVAdEumFf0L4rldMfqfV7+dxLykIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=MChang@suse.com; Received: from BY5PR18MB3140.namprd18.prod.outlook.com (2603:10b6:a03:1a1::17) by BY5PR18MB3282.namprd18.prod.outlook.com (2603:10b6:a03:1ac::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.18; Thu, 26 Mar 2020 04:25:03 +0000 Received: from BY5PR18MB3140.namprd18.prod.outlook.com ([fe80::a404:f256:fbe8:c2d]) by BY5PR18MB3140.namprd18.prod.outlook.com ([fe80::a404:f256:fbe8:c2d%4]) with mapi id 15.20.2856.019; Thu, 26 Mar 2020 04:25:03 +0000 Date: Thu, 26 Mar 2020 12:24:57 +0800 From: Michael Chang To: The development of GNU GRUB CC: Subject: Re: disk/mdraid1x_linux.c:181:15: warning: array subscript ... Message-ID: <20200326042457.GD4258@mercury> References: <9634719282783168194@scdbackup.webframe.org> <20200325072728.GA13446@mercury> <20200325183527.o7zowzpwyrrdwwqb@tomti.i.net-space.pl> <20200326041311.GC4258@mercury> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200326041311.GC4258@mercury> User-Agent: Mutt/1.10.1 (2018-07-13) X-ClientProxiedBy: SN4PR0701CA0032.namprd07.prod.outlook.com (2603:10b6:803:2d::12) To BY5PR18MB3140.namprd18.prod.outlook.com (2603:10b6:a03:1a1::17) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from mercury (36.226.146.226) by SN4PR0701CA0032.namprd07.prod.outlook.com (2603:10b6:803:2d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.20 via Frontend Transport; Thu, 26 Mar 2020 04:25:02 +0000 X-Originating-IP: [36.226.146.226] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6c45e08d-cab3-46e4-29a6-08d7d13da781 X-MS-TrafficTypeDiagnostic: BY5PR18MB3282: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2201; X-Forefront-PRVS: 0354B4BED2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(396003)(376002)(366004)(346002)(136003)(33716001)(478600001)(8936002)(316002)(1076003)(26005)(4326008)(66476007)(6916009)(2906002)(966005)(33656002)(8676002)(66946007)(6496006)(6666004)(9686003)(86362001)(186003)(16526019)(956004)(52116002)(81156014)(81166006)(5660300002)(9576002)(53546011)(66556008)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR18MB3282; H:BY5PR18MB3140.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; Received-SPF: None (protection.outlook.com: suse.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rdCdUMD9DxWf2SZa/lV0G5fh050+oab0RQQfWlso/LH+641Urdya6AXgkCQ//sNOcLb8BDxINj0yeX0IVosNzL5LSpSlhAqyhmJIdmXNLkn4+iHKU4/nypNcEkuaeBubFcoAgG3LQ5706NAxABqSyeaGR1H9Ke74/ntSICsGAM8ykQrphsGtPkFSmzrMsMwkaB5Ib2gumANJ5buN9jSY9oJweMMUJC+xjXfBraASCY4/R6vFHlxDutU3t89yRhujbXtfiH0V3p3zfDK1XbiTVTJ6bs5Wt+FCuUO1b2hg1vZDXM6n0Z/HgjegdzBxIhr/vFB4RGkTh00gX8TYKhqY1SBEcU0t2fb9GnPb5mAPo7XMNPVIQ1f3keJNiegY1DTMg+PGDAanrnV02BfTJ1P1RQoe6hM7gMFobmopGiYnVVqnMEzixYek2Ez+hTh9toaBRy0KgyKY0pnZCITCkqdX/L7/P+2zwy83w3Klv64DN5HFcUlCGpzmxYnkULshUkaGic3w1mlZ4EpKrZgfu2RsOw== X-MS-Exchange-AntiSpam-MessageData: tDbCVhw/fHlJjSc3f4VjVsTR79ppRXHnFVKGjIWekNbahHDEr3vWjCsJASElX7fY6WA7ogUfN1zsJ/mi0dFoAaR/NHn/ylekef67TkKib+lDBlV8VWSehNVZDa2cuvfE5yqx0pfCCukLJATqW7cEvg== X-MS-Exchange-CrossTenant-Network-Message-Id: 6c45e08d-cab3-46e4-29a6-08d7d13da781 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2020 04:25:03.2942 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 856b813c-16e5-49a5-85ec-6f081e13b527 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: NS91woNV+kvqxCCjrPgAIRvZPocwUG4n2GDhUv9k82LkG8yjzCDBlJnEFRZ4UJmO X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3282 X-OriginatorOrg: suse.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 15.124.2.130 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 04:26:47 -0000 On Thu, Mar 26, 2020 at 12:13:11PM +0800, Michael Chang wrote: > On Wed, Mar 25, 2020 at 07:35:27PM +0100, Daniel Kiper wrote: > > On Wed, Mar 25, 2020 at 03:27:28PM +0800, Michael Chang wrote: > > > On Tue, Mar 24, 2020 at 06:54:43PM +0100, Thomas Schmitt wrote: > > [snip] > > > > >From 8666468ac1a35f0678672de5c89a3f062d1aeb39 Mon Sep 17 00:00:00 2001 > > > From: Michael Chang > > > Date: Wed, 25 Mar 2020 14:28:15 +0800 > > > Subject: [PATCH 2/2] zfs: Fix gcc10 error -Werror=zero-length-bounds > > > > > > We bumped into the build error while testing gcc-10 pre-release. > > > > > > In file included from ../../include/grub/file.h:22, > > > from ../../grub-core/fs/zfs/zfs.c:34: > > > ../../grub-core/fs/zfs/zfs.c: In function 'zap_leaf_lookup': > > > ../../grub-core/fs/zfs/zfs.c:2263:44: error: array subscript '' is outside the bounds of an interior zero-length array 'grub_uint16_t[0]' {aka 'short unsigned int[0]'} [-Werror=zero-length-bounds] > > > 2263 | for (chunk = grub_zfs_to_cpu16 (l->l_hash[LEAF_HASH (blksft, h, l)], endian); > > > ../../include/grub/types.h:241:48: note: in definition of macro 'grub_le_to_cpu16' > > > 241 | # define grub_le_to_cpu16(x) ((grub_uint16_t) (x)) > > > | ^ > > > ../../grub-core/fs/zfs/zfs.c:2263:16: note: in expansion of macro 'grub_zfs_to_cpu16' > > > 2263 | for (chunk = grub_zfs_to_cpu16 (l->l_hash[LEAF_HASH (blksft, h, l)], endian); > > > | ^~~~~~~~~~~~~~~~~ > > > In file included from ../../grub-core/fs/zfs/zfs.c:48: > > > ../../include/grub/zfs/zap_leaf.h:72:16: note: while referencing 'l_hash' > > > 72 | grub_uint16_t l_hash[0]; > > > | ^~~~~~ > > > > > > Here I'd like to quote from the gcc document [1] which seems to be best > > > to explain what is going on here. > > > > > > "Declaring zero-length arrays in other contexts, including as interior > > > members of structure objects or as non-member objects, is discouraged. > > > Accessing elements of zero-length arrays declared in such contexts is > > > undefined and may be diagnosed." > > > > > > The l_hash[0] is apparnetly an interior member to the enclosed structure > > > while l_entries[0] is the trailing member. And the offending code tries > > > to access members in l_hash[0] array that triggers the diagnose. > > > > > > Given that the l_entries[0] is used to get proper alignment to access > > > leaf chunks, we can accomplish the same thing through the ALIGN_UP macro > > > thus eliminating l_entries[0] from the structure. In this way we can > > > pacify the warning as l_hash[0] now becomes the last member to the > > > enclosed structure. > > > > > > [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > > > > > > Signed-off-by: Michael Chang > > > --- > > > grub-core/fs/zfs/zfs.c | 7 ++++--- > > > include/grub/zfs/zap_leaf.h | 1 - > > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > > > diff --git a/grub-core/fs/zfs/zfs.c b/grub-core/fs/zfs/zfs.c > > > index 2f72e42bf..f38f5b102 100644 > > > --- a/grub-core/fs/zfs/zfs.c > > > +++ b/grub-core/fs/zfs/zfs.c > > > @@ -141,9 +141,10 @@ ZAP_LEAF_NUMCHUNKS (int bs) > > > static inline zap_leaf_chunk_t * > > > ZAP_LEAF_CHUNK (zap_leaf_phys_t *l, int bs, int idx) > > > { > > > - return &((zap_leaf_chunk_t *) (l->l_entries > > > - + (ZAP_LEAF_HASH_NUMENTRIES(bs) * 2) > > > - / sizeof (grub_properly_aligned_t)))[idx]; > > > + grub_properly_aligned_t *l_entries; > > > + > > > + l_entries = (grub_properly_aligned_t *) ALIGN_UP((grub_addr_t)l->l_hash, sizeof (grub_properly_aligned_t)); > > > + return &((zap_leaf_chunk_t *) (l_entries + ZAP_LEAF_HASH_NUMENTRIES(bs)))[idx]; > > > > Why are you skipping "* 2) / sizeof (grub_properly_aligned_t)" here? Ah, indeed I had mistake here. It has to take "HASH_NUMENTRIES * 2) / sizeof (grub_properly_aligned_t)" for computing the entry number of l_entries from given HASH_NUMENTRIES. I will fix that and repost patches. Thanks, Michael > It is based on this comment before the function. > > "The chunks start immediately after the hash table. The end of the hash > table is at l_hash + HASH_NUMENTRIES, which we simply cast to a > chunk_t." > > I suppose the magic number "2" could be "sizeof (l->l_hash[0])", so the > computatio1n is likely to get number of entries for l->l_entries[] from > which we can take address as the chunk start. And since it is indexed by > type grub_properly_aligned_t, the alignment is automagically satisfied. > > > > > And could you add following excerpt from [1] to the commit message: > > Although the size of a zero-length array is zero, an array member of > > this kind may increase the size of the enclosing type as a result of > > tail padding. The offset of a zero-length array member from the > > beginning of the enclosing structure is the same as the offset of an > > array with one or more elements of the same type. The alignment of a > > zero-length array is the same as the alignment of its elements. > > OK. I will do so. > > > > > > } > > > > > > static inline struct zap_leaf_entry * > > > diff --git a/include/grub/zfs/zap_leaf.h b/include/grub/zfs/zap_leaf.h > > > index 95c67dcba..11447c166 100644 > > > --- a/include/grub/zfs/zap_leaf.h > > > +++ b/include/grub/zfs/zap_leaf.h > > > @@ -70,7 +70,6 @@ typedef struct zap_leaf_phys { > > > */ > > > > > > grub_uint16_t l_hash[0]; > > > - grub_properly_aligned_t l_entries[0]; > > > } zap_leaf_phys_t; > > > > > > typedef union zap_leaf_chunk { > > > -- > > > 2.16.4 > > > > > > > May I ask you to repost the patches in the proper format and CC all > > people involved in the discussion? > > OK. I will. > > Thanks, > Michael > > > > > Daniel > > > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/grub-devel