From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 80F5A3858CDA for ; Thu, 11 May 2023 22:52:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 80F5A3858CDA Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.99,268,1677571200"; d="scan'208";a="4990513" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 11 May 2023 14:52:30 -0800 IronPort-SDR: ocSW3JRScdrJzbDdvklpCVOJ/yoa4V+KWMngDsMe4FXNS2rV6K4a7QpkhVAVo2KmEf2KoTCk/5 yBHUAf0rhlOtDUuhsXskKlnz84jMX+/W3BzSV4QK6+/JLIlPqIAHHC6Nkvap7ftyOS2GZ3WQ2N /cAaPUvuLdEG+RHvS7Gs1cAXJzU+kbBSwFQYbI/OvGOW0xDv+lr+PxLaMKVEKYtQLaCdXN4obf xUYaVkXMF69Hf4sqrIQh+28RdJlka5NTRBJfUaUjUjq2UXsXHGbhX/yzCnJiQCUVIGdhvzcjqO EuY= Date: Thu, 11 May 2023 22:52:25 +0000 From: Joseph Myers To: Kees Cook CC: Alejandro Colomar , GCC , Alejandro Colomar , Andrew Clayton , Andrew Clayton , Subject: Re: [wish] Flexible array members in unions In-Reply-To: <202305111514.576EB7F@keescook> Message-ID: References: <44940599-7b43-99f6-5b09-4f050d645c7b@gmail.com> <202305111158.C78642624@keescook> <74ee73d2-04e-ea8-9430-93929446e925@codesourcery.com> <202305111410.CFE0875F@keescook> <202305111514.576EB7F@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-14.mgc.mentorg.com (139.181.222.14) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3106.8 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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, 11 May 2023, Kees Cook via Gcc wrote: > Okay, understood. If this is a C-only thing, we can ignore the C++ > impact. We're a lot more careful lately in WG14 about checking for C++ compatibility issues and expecting approval from the liaison group for anything with possible compatibility concerns for syntax in the common subset of C and C++. So, no, we can't ignore the C++ impact for adding empty types; it would need careful consideration in the liaison group. > What depends on the "different objects have different addresses" > principle? And why do unions not break this -- they could point to the > same locations within the object? And don't flexible arrays already need > special handling in this regard? "including a pointer to an object and a subobject at its beginning" and "one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space" are both cases included in the semantics for comparison operators. If you allow zero-size objects you get more special cases there (and quite possibly affect optimizations based on points-to analysis that can determine pointers are based on different objects, if an object is not known at compile time to have nonzero size). -- Joseph S. Myers joseph@codesourcery.com