From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CFBEC35242 for ; Wed, 12 Feb 2020 00:21:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E382A206CC for ; Wed, 12 Feb 2020 00:21:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="VZ6ckbfR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728087AbgBLAVu (ORCPT ); Tue, 11 Feb 2020 19:21:50 -0500 Received: from mail-io1-f66.google.com ([209.85.166.66]:40449 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727985AbgBLAVt (ORCPT ); Tue, 11 Feb 2020 19:21:49 -0500 Received: by mail-io1-f66.google.com with SMTP id x1so178146iop.7 for ; Tue, 11 Feb 2020 16:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=znb551cSk4SwLxhNrEmBfKq1pXuZl4kKW4lbTxGwGf0=; b=VZ6ckbfRbXGkd5NeS4Ei/5MZP/bHqLs4i414YLfooFZWB/vpkXt3IRgOWOHViumSmw d1dqbNOZEIA0wrY2USJ21lXm6Bf+vZ5MNqF4XFQaUy82r4ioVWSOAy2wxI6esOe4xUd5 Pj0gKdW0s+lwOTFimBjaR2PgezxkqAafgvdOo4KIJjksO/DAYzzGhkJdfeLdtu7dc3D8 lA5FUgjcvQ0OpSn5Jx+Qa0wDtDfIonHBAaPjMwsxTyl/oY3XrGZZxXwixUN/WWNMwSfd T3eYxWdvx/AdiShb5/amBwznu9N2xDiNXoBrwaPpwqx55F19thSdPSVjxxHnBWKL1QPK BPWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=znb551cSk4SwLxhNrEmBfKq1pXuZl4kKW4lbTxGwGf0=; b=ONFevrqXyze0xYK02sByP8HZHyFP6BHTUbWxzT1XuaFvfNl9ndAyxm4hqi8brHBM2C Tc75Hv2EhSk7zirBlNQGGYpIyk6HgdSBE6Oi367wulFwFDaBRW0yo4XM58kvD7sDOEdE BXhgBr0f70q5G08lMmkLhojyf4hyp4MVLiroa8r9mb+zc8Yydn0VDNfT/1ooc7FcNJtI dOXn/DCQuWO0hKsPsUkC2CWHH7gGR6phlpMxBZ+txeAUAPXvpodkzuW4fFsvZcC+yiSt xlgoUHeBGGQ/40mYPAPoxEFpbETtYTJ+Jtu3nsZoqSV1it6qyo+18lxM8W7i97DfR/Lt 8OBQ== X-Gm-Message-State: APjAAAUSLb35e/ixTs00Dj81zz/bqAxX4tekG7ogOBVp/NZDQjB5KvAg +octeHNPn6jQSuX04/Tyachqg1/LcspAig== X-Google-Smtp-Source: APXvYqxnRq6BGvwAHW2U261ceZ/bNuGg0tou3R07qwEpFfCKWQdGO9ZqNUDWl6Avc9BLocaETXZ3DQ== X-Received: by 2002:a5e:9b01:: with SMTP id j1mr15005204iok.27.1581466907709; Tue, 11 Feb 2020 16:21:47 -0800 (PST) Received: from [172.22.22.10] (c-73-185-129-58.hsd1.mn.comcast.net. [73.185.129.58]) by smtp.googlemail.com with ESMTPSA id q90sm1797509ili.27.2020.02.11.16.21.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Feb 2020 16:21:46 -0800 (PST) Subject: Re: [greybus-dev] [PATCH] staging: greybus: Replace zero-length array with flexible-array member To: "Gustavo A. R. Silva" , Johan Hovold , Alex Elder , Greg Kroah-Hartman Cc: devel@driverdev.osuosl.org, greybus-dev@lists.linaro.org, linux-kernel@vger.kernel.org References: <20200211211219.GA673@embeddedor> From: Alex Elder Message-ID: <7ac2012c-6d22-dcc2-7c96-b9d6d578706a@linaro.org> Date: Tue, 11 Feb 2020 18:21:13 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/11/20 4:47 PM, Gustavo A. R. Silva wrote: > > > On 2/11/20 16:15, Alex Elder wrote: >> On 2/11/20 3:12 PM, Gustavo A. R. Silva wrote: >>> 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 >>> inadvertenly introduced[3] to the codebase from now on. >>> >>> 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 >>> --- >>> drivers/staging/greybus/raw.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/staging/greybus/raw.c b/drivers/staging/greybus/raw.c >>> index 838acbe84ca0..2b301b2aa107 100644 >>> --- a/drivers/staging/greybus/raw.c >>> +++ b/drivers/staging/greybus/raw.c >>> @@ -30,7 +30,7 @@ struct gb_raw { >>> struct raw_data { >>> struct list_head entry; >>> u32 len; >>> - u8 data[0]; >>> + u8 data[]; >>> }; >>> >>> static struct class *raw_class; >>> >> >> Does the kamlloc() call in receive_data() have any problems >> with the sizeof(*raw_data) passed as its argument? >> > > Not in this case. It'd be different with a one-element array (u8 data[1]), > though. > >> I'm not entirely sure what sizeof(struct-with-flexible-array-member) >> produces. >> > > The same as sizeof(struct-with-zero-length-array): > > "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] > > [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html I saw that, but I wondered what the standard says (and whether Clang produces the same result). I found this in a draft standard, and I guess we can assume it applies here: "...the size of the structure is as if the flexible array member were omitted except that it may have more trailing padding than the omission would imply." Looks good to me. Reviewed-by: Alex Elder > > -- > Gustavo > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB214C35242 for ; Wed, 12 Feb 2020 00:21:53 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9F6AC206CC for ; Wed, 12 Feb 2020 00:21:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="VZ6ckbfR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F6AC206CC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id CEF852052B; Wed, 12 Feb 2020 00:21:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+O2Dn6pvL8A; Wed, 12 Feb 2020 00:21:50 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by silver.osuosl.org (Postfix) with ESMTP id 69AC220119; Wed, 12 Feb 2020 00:21:50 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by ash.osuosl.org (Postfix) with ESMTP id 467541BF9B2 for ; Wed, 12 Feb 2020 00:21:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 40FBD87327 for ; Wed, 12 Feb 2020 00:21:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2t5ueC76yDtC for ; Wed, 12 Feb 2020 00:21:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by hemlock.osuosl.org (Postfix) with ESMTPS id 77E4686F1B for ; Wed, 12 Feb 2020 00:21:48 +0000 (UTC) Received: by mail-io1-f66.google.com with SMTP id d15so200861iog.3 for ; Tue, 11 Feb 2020 16:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=znb551cSk4SwLxhNrEmBfKq1pXuZl4kKW4lbTxGwGf0=; b=VZ6ckbfRbXGkd5NeS4Ei/5MZP/bHqLs4i414YLfooFZWB/vpkXt3IRgOWOHViumSmw d1dqbNOZEIA0wrY2USJ21lXm6Bf+vZ5MNqF4XFQaUy82r4ioVWSOAy2wxI6esOe4xUd5 Pj0gKdW0s+lwOTFimBjaR2PgezxkqAafgvdOo4KIJjksO/DAYzzGhkJdfeLdtu7dc3D8 lA5FUgjcvQ0OpSn5Jx+Qa0wDtDfIonHBAaPjMwsxTyl/oY3XrGZZxXwixUN/WWNMwSfd T3eYxWdvx/AdiShb5/amBwznu9N2xDiNXoBrwaPpwqx55F19thSdPSVjxxHnBWKL1QPK BPWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=znb551cSk4SwLxhNrEmBfKq1pXuZl4kKW4lbTxGwGf0=; b=bHFYf6CL6A354mJO/e7ATfmBAaOJhhKDq3ncMA9AECPGaAbEV/VgzcumKpNsuFGJY2 JTXa1AZT/bQ+pAw2q6YZyA+KBYU6VI5h96QEw6vzx+8hMAcCHQP5SwSyCkCvPo3Qo31Y eAhtRGJcX+Hdqx8cgaD1UzcKiQElBlV/UVp8CRTN0O2AdP5Npzuhb09LnYD93l3wMURC RR2imXfWdT1oDllDyOzGA/7PDFxDL9TdVgmDp5Y9zALNoUJFmBR+6f00nwigwvWe0wmg AHEl/uMYv4r8O9P+I+CgTOSA9iYw09JgXxkvI2zd4RPeVOMXXiFy8v6JPyh0Kgvd+2aL S1lw== X-Gm-Message-State: APjAAAVhJ0jykNb+mRayYRRPmMX/KzPSsals6F38EtSbpDX7vt5WOWy2 VLEeCKtotHiAGbdaBXZJ7Sy0Eg== X-Google-Smtp-Source: APXvYqxnRq6BGvwAHW2U261ceZ/bNuGg0tou3R07qwEpFfCKWQdGO9ZqNUDWl6Avc9BLocaETXZ3DQ== X-Received: by 2002:a5e:9b01:: with SMTP id j1mr15005204iok.27.1581466907709; Tue, 11 Feb 2020 16:21:47 -0800 (PST) Received: from [172.22.22.10] (c-73-185-129-58.hsd1.mn.comcast.net. [73.185.129.58]) by smtp.googlemail.com with ESMTPSA id q90sm1797509ili.27.2020.02.11.16.21.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Feb 2020 16:21:46 -0800 (PST) Subject: Re: [greybus-dev] [PATCH] staging: greybus: Replace zero-length array with flexible-array member To: "Gustavo A. R. Silva" , Johan Hovold , Alex Elder , Greg Kroah-Hartman References: <20200211211219.GA673@embeddedor> From: Alex Elder Message-ID: <7ac2012c-6d22-dcc2-7c96-b9d6d578706a@linaro.org> Date: Tue, 11 Feb 2020 18:21:13 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, greybus-dev@lists.linaro.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" On 2/11/20 4:47 PM, Gustavo A. R. Silva wrote: > > > On 2/11/20 16:15, Alex Elder wrote: >> On 2/11/20 3:12 PM, Gustavo A. R. Silva wrote: >>> 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 >>> inadvertenly introduced[3] to the codebase from now on. >>> >>> 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 >>> --- >>> drivers/staging/greybus/raw.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/staging/greybus/raw.c b/drivers/staging/greybus/raw.c >>> index 838acbe84ca0..2b301b2aa107 100644 >>> --- a/drivers/staging/greybus/raw.c >>> +++ b/drivers/staging/greybus/raw.c >>> @@ -30,7 +30,7 @@ struct gb_raw { >>> struct raw_data { >>> struct list_head entry; >>> u32 len; >>> - u8 data[0]; >>> + u8 data[]; >>> }; >>> >>> static struct class *raw_class; >>> >> >> Does the kamlloc() call in receive_data() have any problems >> with the sizeof(*raw_data) passed as its argument? >> > > Not in this case. It'd be different with a one-element array (u8 data[1]), > though. > >> I'm not entirely sure what sizeof(struct-with-flexible-array-member) >> produces. >> > > The same as sizeof(struct-with-zero-length-array): > > "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] > > [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html I saw that, but I wondered what the standard says (and whether Clang produces the same result). I found this in a draft standard, and I guess we can assume it applies here: "...the size of the structure is as if the flexible array member were omitted except that it may have more trailing padding than the omission would imply." Looks good to me. Reviewed-by: Alex Elder > > -- > Gustavo > _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel