From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 747CA3858C53 for ; Thu, 2 Feb 2023 17:05:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 747CA3858C53 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=chromium.org Received: by mail-pf1-x42b.google.com with SMTP id ay1so1664407pfb.7 for ; Thu, 02 Feb 2023 09:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:subject:cc:to:from:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=APzphUIvx3gx8wBVev6Imt2B5V96ZnLILAfYT/dqJ7k=; b=eyfBAIQ0R7SGQoI57e0Z1XG6+BeBM/A0VaTJRd8PXMtxQdyskgvWNADZzNpeOF/+l2 TMFsehhSM6sWyB6n9i8Lu2cZxblCPOjDeZ8NQJH73+YYeIGeGisMxUrts0nbV29p36zZ xsljvW31PQcX6891cicCX0I32hWrpV3hSIOfY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:subject:cc:to:from:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=APzphUIvx3gx8wBVev6Imt2B5V96ZnLILAfYT/dqJ7k=; b=M2idcSOPDZgFmgspR4TaI2nq1N7s6DgfrQhfYa5Z1mVT0uY6wE5/1tjbpq7tJZmxoT XK8eTUw3FQNEb+HoYNqbR8cDgvKHUa96PKHQpM6yCbV0+4O5Ct4GhlZ6jjbS48pEFq2g L45WxkEKefCt9KyG6sbRD6sUm3Or7TulJ9noPRb75bPe7MdQHBbEH2xpuIzQgbm6p/TZ 7SMKjoueOcL1YIBldfgbYSwU4oVa27obWrl72hG+u5zvjKv14FhaMOJMU8c5JUTHjRdm vv9zKqvWH84v9oGleRwMdsVuA0NzBlzXPU4n/1BhUmPIpJjryHdebfUb4YDUtRw6E2WU I8Ew== X-Gm-Message-State: AO0yUKVjdfatc/Q6LGAGfbHS+tnjnBkzBD1niCOv76hvUqRBwbOWPYQq iLDbGtZWF8ccKiCYnIcF0klAwg== X-Google-Smtp-Source: AK7set8n7QNOvPpzq73DvBuviaDYOHBKTboMCvTWTnBph7flTl+UaUfVtFbvjCbcsPKsgUmPP/nyNQ== X-Received: by 2002:a62:1dc2:0:b0:592:4502:fb0 with SMTP id d185-20020a621dc2000000b0059245020fb0mr6467195pfd.0.1675357521420; Thu, 02 Feb 2023 09:05:21 -0800 (PST) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id i26-20020aa787da000000b0059435689e36sm1564265pfo.170.2023.02.02.09.05.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Feb 2023 09:05:20 -0800 (PST) Message-ID: <63dbed50.a70a0220.3e5e5.24a2@mx.google.com> X-Google-Original-Message-ID: <202302021703.@keescook> Date: Thu, 2 Feb 2023 17:05:20 +0000 From: Kees Cook To: Qing Zhao Cc: Richard Biener , Siddhesh Poyarekar , gcc Patches , "Joseph S. Myers" Subject: Re: [PATCH 2/2] Documentation Update. References: <20230131141140.3610133-1-qing.zhao@oracle.com> <20230131141140.3610133-3-qing.zhao@oracle.com> <1AB22124-10D2-416D-B1BD-D4FF728AB0E2@oracle.com> <6832ED41-E086-49E0-8BD2-51387710DECD@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6832ED41-E086-49E0-8BD2-51387710DECD@oracle.com> X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Feb 02, 2023 at 02:31:53PM +0000, Qing Zhao wrote: > > > On Feb 2, 2023, at 3:33 AM, Richard Biener wrote: > > > > On Wed, 1 Feb 2023, Siddhesh Poyarekar wrote: > > > >> On 2023-02-01 13:24, Qing Zhao wrote: > >>> > >>> > >>>> On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar > >>>> wrote: > >>>> > >>>> On 2023-01-31 09:11, Qing Zhao wrote: > >>>>> Update documentation to clarify a GCC extension on structure with > >>>>> flexible array member being nested in another structure. > >>>>> gcc/ChangeLog: > >>>>> * doc/extend.texi: Document GCC extension on a structure containing > >>>>> a flexible array member to be a member of another structure. > >>>> > >>>> Should this resolve pr#77650 since the proposed action there appears to be > >>>> to document these semantics? > >>> > >>> My understanding of pr77650 is specifically for documentation on the > >>> following case: > >>> > >>> The structure with a flexible array member is the middle field of another > >>> structure. > >>> > >>> Which I added in the documentation as the 2nd situation. > >>> However, I am still not very comfortable on my current clarification on this > >>> situation: how should we document on > >>> the expected gcc behavior to handle such situation? > >> > >> I reckon wording that dissuades programmers from using this might be > >> appropriate, i.e. don't rely on this and if you already have such nested flex > >> arrays, change code to remove them. > >> > >>>>> +In the above, @code{flex_data.data[]} is allowed to be extended flexibly > >>>>> to > >>>>> +the padding. E.g, up to 4 elements. > >> > >> """ > >> ... Relying on space in struct padding is bad programming practice and any > >> code relying on this behaviour should be modified to ensure that flexible > >> array members only end up at the ends of arrays. The `-pedantic` flag should > >> help identify such uses. > >> """ > >> > >> Although -pedantic will also flag on flex arrays nested in structs even if > >> they're at the end of the parent struct, so my suggestion on the warning is > >> not really perfect. > > > > Wow, so I checked and we indeed accept > > > > struct X { int n; int data[]; }; > > struct Y { struct X x; int end; }; > > > > and -pedantic says > > > > t.c:2:21: warning: invalid use of structure with flexible array member > > [-Wpedantic] > > 2 | struct Y { struct X x; int end; }; > > | > > Currently, -pedantic report the same message for flex arrays nested in structs at the end of the parent struct AND in the middle of the parent struct. > Shall we distinguish them and report different warning messages in order to discourage the latter case? > > And at the same time, in the documentation, clarify these two situations, and discourage the latter case at the same time as well? > > > > > > and clang reports > > > > t.c:2:21: warning: field 'x' with variable sized type 'struct X' not at > > the end of a struct or class is a GNU extension > > [-Wgnu-variable-sized-type-not-at-end] > > struct Y { struct X x; int end; }; > > > > ^ > > Clang’s warning message is clearer. > > > > looking at PR77650 what seems missing there is the semantics of this > > extension as expected/required by the glibc use. comment#5 seems > > to suggest that for my example above its expected that > > Y.x.data[0] aliases Y.end?! > > Should we mentioned this alias relationship in the doc? > > > There must be a better way to write > > the glibc code and IMHO it would be best to deprecate this extension. > > Agreed. This is really a bad practice, should be deprecated. > We can give warning first in this release, and then deprecate this extension in a latter release. Right -- this can lead (at least) to type confusion and other problems too. We've been trying to remove all of these overlaps in the Linux kernel. I mention it the "Overlapping composite structure members" section at https://people.kernel.org/kees/bounded-flexible-arrays-in-c -- Kees Cook