From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 452043858033 for ; Thu, 9 Feb 2023 16:46:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 452043858033 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-x430.google.com with SMTP id g9so1715723pfo.5 for ; Thu, 09 Feb 2023 08:46:19 -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=ibrrp6AKXZ1h2U7Vl+PvYgO/w5tDF1stFuaSRncgOAA=; b=BpAawTFW4OsiZwAKPIM0PbOfqjutjuCKc+z8cqlyHv9BbR+nPa2eLJxJMd0fqT4sCh dzSMFSHbsakhLCZ9xiOEZ0WzJYjUW6iSKIS+0/ATQrf+2xrcdloWayh5uH3vsS1HGuhe ita+eApIahz90M6TKiWApyNV8u+QdJo927LHs= 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=ibrrp6AKXZ1h2U7Vl+PvYgO/w5tDF1stFuaSRncgOAA=; b=OGebSpFBQrWG8kEwjPN4codvIUCaJvIKBmcEvxZEf0TJK4eHfdCtefCh+sVdAVTdSr BeWrgSUSzx5S0kZ1MEiKlfz9TnKvvFOHcQezKjo7VHegxj3t2KQpl6JvDnsLIZyk5gay 5GGQMT58KGUbq8Mu3qtUTJtkR9Orz/stjflLZtjhdU9Mc9htxdY3a2I+HxKEJ31aMELF blnGHYGDzF67CVYcry6UPZc2he7qovTRc4c+qW0WPcTNTbEpQ6PCgmWukqZZ+j+JJK15 1fI03vQSZAANSLyT6Ryv9PUEmxSFUAjAgzWSliHy4wCLtXKM7SduQ+5TiNYbkp+cC3vT zE2w== X-Gm-Message-State: AO0yUKUa8qGUA3P+psoWJ2YFjyNUUWsz+vzVtPEeDR0yaDcC1xnHJ8vf rOezh6kV2pdsQoC0EfRe7S8kpA== X-Google-Smtp-Source: AK7set+InZmwIRqZqlp9logc6PaTaZHdPIdueOCo+S1c4dVDKG29Zfhqq58NBGKI8JaM+pzsiFjcEg== X-Received: by 2002:a62:17ca:0:b0:5a8:4eef:4dc9 with SMTP id 193-20020a6217ca000000b005a84eef4dc9mr3239560pfx.7.1675961178172; Thu, 09 Feb 2023 08:46:18 -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 j10-20020aa7800a000000b005893f281d43sm1663197pfi.27.2023.02.09.08.46.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Feb 2023 08:46:17 -0800 (PST) Message-ID: <63e52359.a70a0220.11fe3.2e86@mx.google.com> X-Google-Original-Message-ID: <202302090843.@keescook> Date: Thu, 9 Feb 2023 08:46:17 -0800 From: Kees Cook To: Qing Zhao Cc: Richard Biener , Joseph Myers , "gcc-patches@gcc.gnu.org" , "siddhesh@gotplt.org" Subject: Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832] References: <4E515AA5-2069-497E-A301-EC8ED744E780@oracle.com> <367EBE15-1675-4D29-A9C2-A4A57FA4DB62@oracle.com> <2184ee29-9a36-e85-11c5-81c47aa22055@codesourcery.com> <91678405-D50E-405A-98FB-F3BA6888577E@oracle.com> <2AB95191-B5D9-41AC-916A-C57ED20DF55E@oracle.com> <17bc7992-23b6-63dc-3a3a-1be016d3bbb@codesourcery.com> <50AC7191-4B2D-4BAE-8DEA-DE9CC21C4787@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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,KAM_SHORT,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 09, 2023 at 02:40:57PM +0000, Qing Zhao wrote: > So, the major question here is: > > in addition to the C99 standard flexible array member [ ], shall we include [0], [1] or even [4] into this extension, and treat the structure with a trailing [0], [1], or [4] embedded into another structure/union still as flexible-sized? > > I think that we might need to limit this extension ONLY to C99 standard FAM [ ]. All other [0], [1], or [4] should be excluded from this extension. The reasons are: > > 1. The real usages of such GCC extension (embedding structure with FAM into another structure/union), as my understanding, the old glibc’s <_G_config.h> (https://gcc.gnu.org/legacy-ml/gcc-patches/2002-08/msg01149.html), and the bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832, ONLY involved C99 standard FAM; > > 2. Embedding a structure with C99 FAM [] into the end of another structure, and still treat it flexible sized might have more usages, and as discussed with Kees, it might be reasonable to promote this into a C standard later if needed. > > So, based on this consideration, I think I should only document the following as GCC extension: > > struct flex { int length; char data[ ]; }; > struct out_flex { int m; struct flex flex_data; }; > > Issue warnings for the following: (when the structure is not at the end) > > struct out_flex_mid { struct flex flex_data; int m}; > > > However, for the trailing [0], [1], or [4], when such structure embedded into the end of another structure, We should NOT treat the outer structure as flexible sized. > Logically, we will NOT issue warnings when such structure is not at the end. > > Let me know if you have any comment or suggestions. FWIW this all sounds correct to me. -- Kees Cook