Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1683603ybk; Mon, 11 May 2020 01:37:16 -0700 (PDT) X-Google-Smtp-Source: APiQypLiziIG5TbrSDNIvqxaVUD5A73ooxp7kfJyEFYN6IGJyTFBstDLKjjKZ2SJnYxgTHDPoGDu X-Received: by 2002:a17:906:13d1:: with SMTP id g17mr12657532ejc.162.1589186236111; Mon, 11 May 2020 01:37:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589186236; cv=none; d=google.com; s=arc-20160816; b=VCPhORvd8Pq7hmutUPUyPQcGLpSzNmBhtbZ4ZXIbKGGG9JaHtC/VwWzrhlE5HfRWXr 8IT/hOGuUXXSdQlXaTBqf49pYo/iKMd3dImAg6MvIwfHUV+e2vguW/2gn5vg/DFVphLH fM7MdzpVdVxOslXJNNXAysTYUvYVj+nNUrYe8hnsOfmJ4ah0CVqm+10aZ/uZI7d+K/vg rwBb0Vnx8evWOVPILdQo3NE7nzD4O6oC+ZPjCpTp22KJtmc/+MxRVMMpX3lamCcM2Lac 2d57MIF/I+EitY4b8CvC1CZwfl/SG29GkNPS2W3+EYbfj85S3MHEKKUIhVH8rQH4P+RR GEmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=zQtr2kkKKa7wTW8so4zHa5iaYxCBXJi2QxFdWbRJ++k=; b=EPzm1LOpPKTLl6xulvWTKMIyzw3x0C6LugWA9yJv5vifGYvwo4WsXxi4NHUP6oilYp m0ZFuGTOVh1IPIoNkXfMvMTbMpWQze20UAEQNbJvnXhxdo/99PncbvlpUMBxmwXUPc3V eh2ewhPJomgZOT6eR0Lw6pm6zsx6cWS12N5lv5ujlr3OyJynOYOqszopllKT9CQ251Xs D5O2/mBmzfxBQNLcpHg9JbGgEopPBUxueoDfwVlQ2TtZon6PFDcTtyz1dqx2ME0JiNrO 50boogATaPmJP/QCD27HQpOx+BBMCMl0AuOoCy6oA4uS+xcvg1dSCrlf+V6HwGkHw3Xj FcuA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q4si5304725eji.14.2020.05.11.01.36.53; Mon, 11 May 2020 01:37:16 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728841AbgEKIdk (ORCPT + 99 others); Mon, 11 May 2020 04:33:40 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:4387 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728344AbgEKIdj (ORCPT ); Mon, 11 May 2020 04:33:39 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id B3EF34AF09197E774942; Mon, 11 May 2020 16:33:36 +0800 (CST) Received: from [127.0.0.1] (10.166.213.7) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.487.0; Mon, 11 May 2020 16:33:35 +0800 Subject: Re: [PATCH] scsi: libsas: Replace zero-length array with flexible-array To: "Gustavo A. R. Silva" , "James E.J. Bottomley" , "Martin K. Petersen" CC: , References: <20200507192147.GA16206@embeddedor> From: Jason Yan Message-ID: <56d7568f-ac24-fef0-e51f-4523cc75f26f@huawei.com> Date: Mon, 11 May 2020 16:33:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <20200507192147.GA16206@embeddedor> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.166.213.7] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ?? 2020/5/8 3:21, Gustavo A. R. Silva ะด??: > The current codebase makes use of the zero-length array language > extension to the C90 standard, but the preferred mechanism to declare > variable-length types such as these ones is a flexible array member[1][2], > introduced in C99: > > struct foo { > int stuff; > struct boo array[]; > }; > > By making use of the mechanism above, we will get a compiler warning > in case the flexible array does not occur last in the structure, which > will help us prevent some kind of undefined behavior bugs from being > inadvertently introduced[3] to the codebase from now on. > > Also, notice that, dynamic memory allocations won't be affected by > this change: > > "Flexible array members have incomplete type, and so the sizeof operator > may not be applied. As a quirk of the original implementation of > zero-length arrays, sizeof evaluates to zero."[1] > > sizeof(flexible-array-member) triggers a warning because flexible array > members have incomplete type[1]. There are some instances of code in > which the sizeof operator is being incorrectly/erroneously applied to > zero-length arrays and the result is zero. Such instances may be hiding > some bugs. So, this work (flexible-array member conversions) will also > help to get completely rid of those sorts of issues. > > This issue was found with the help of Coccinelle. > > [1]https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html > [2]https://github.com/KSPP/linux/issues/21 > [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") > > Signed-off-by: Gustavo A. R. Silva Reviewed-by: Jason Yan