From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id 51EBE3858C54 for ; Fri, 12 May 2023 00:26:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 51EBE3858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-3f42d937d61so33632785e9.3 for ; Thu, 11 May 2023 17:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683851166; x=1686443166; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=/pdxt8598+AuKVRd83LFJjNgz5XEcYwttkCXlHDv37Q=; b=cQEGndHR1VI0rkWSwVwluTYVo6FbB2gsO09tWkjnXSZ6/fz6s8RplZDZMc07JOUOBX fGAfWmrrLNMQ5SGMwKjfSQvU0WTpZyinO5Dy2yUZEiJrtzba07H4lwtM0totlbwLzXEF OXjbSp1qKlJtVWr64nVjngAZX4PsfbeB70cFad8UOH2ei9t+J5xdxl+pOpJ8Axh3kTfF VR9HkyMHtxhyygtHAcg5TVh0Tzer5+aOWDRNTxVavbRwMA6N/DED3AvO0BtBhkxMcPc4 Kszj+1c1BEyDvTcNV0oPjwyMJUBZ7i5g5wgyc654PbtT71UGtju9lJVJVUy+3B0O0RCR sqqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683851166; x=1686443166; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=/pdxt8598+AuKVRd83LFJjNgz5XEcYwttkCXlHDv37Q=; b=I3tnesEyX+t3+77YVhWbweidgcONldNmhrRlfaPU5FxuMIBqDc5B9i0WMQqRcWyoBm 5Y5fryE2eaRIvIVaoBkQmuUM8t/z7CCumsWhnttGr3lPc4nUJNPJkGjgS1CPc2ud44GB 39CLNSzQRbyOkJ4tBoq0ziXZt+7ENl8NHXyvSiR2dNZ121eVw8K7usYKC9DnEhkGhCDc 9IFLyCo6oIkURl1PIRoOnXmEohM0LqsJbUQgKVJ7kgFgb5YM9Z4B0O8htKDEtoBcG77A +lh8Tp2cMckqm975WgsbxLOoJTiiPFo6B8YsujRM7E0eqKfKTTP15nSSK4DbEHNTmUEJ Kddg== X-Gm-Message-State: AC+VfDwkW1QDnPGRHGpNK382TC81Ya5dgAq5NTmf0w++gAvCfXpSvXy5 zwwD/ugjHbKkgkX2xkYC/HU= X-Google-Smtp-Source: ACHHUZ5r4snoWkmpes4sbbKk60PJAGOQUJDpuEcyLF4BWWbBtrWcZSjegbTSNiwoXDluuRUTav4SLg== X-Received: by 2002:a1c:6a18:0:b0:3f4:294d:8529 with SMTP id f24-20020a1c6a18000000b003f4294d8529mr10076143wmc.19.1683851165712; Thu, 11 May 2023 17:26:05 -0700 (PDT) Received: from [192.168.0.160] ([170.253.51.134]) by smtp.gmail.com with ESMTPSA id v2-20020a1cf702000000b003f32f013c3csm27148359wmh.6.2023.05.11.17.26.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 May 2023 17:26:05 -0700 (PDT) Message-ID: <240b09b1-ea14-4a96-5091-7fe50d049005@gmail.com> Date: Fri, 12 May 2023 02:25:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [wish] Flexible array members in unions Content-Language: en-US To: Joseph Myers , Kees Cook Cc: GCC , Alejandro Colomar , Andrew Clayton , Andrew Clayton , linux-hardening@vger.kernel.org References: <44940599-7b43-99f6-5b09-4f050d645c7b@gmail.com> <202305111158.C78642624@keescook> <74ee73d2-04e-ea8-9430-93929446e925@codesourcery.com> <202305111410.CFE0875F@keescook> <202305111514.576EB7F@keescook> From: Alejandro Colomar In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Fe8uTpjyiA6kjMm0Y7SKYAhS" X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Fe8uTpjyiA6kjMm0Y7SKYAhS Content-Type: multipart/mixed; boundary="------------ySemPXGO5xT86AvfUHBQi3k0"; protected-headers="v1" From: Alejandro Colomar To: Joseph Myers , Kees Cook Cc: GCC , Alejandro Colomar , Andrew Clayton , Andrew Clayton , linux-hardening@vger.kernel.org Message-ID: <240b09b1-ea14-4a96-5091-7fe50d049005@gmail.com> Subject: Re: [wish] Flexible array members in unions References: <44940599-7b43-99f6-5b09-4f050d645c7b@gmail.com> <202305111158.C78642624@keescook> <74ee73d2-04e-ea8-9430-93929446e925@codesourcery.com> <202305111410.CFE0875F@keescook> <202305111514.576EB7F@keescook> In-Reply-To: --------------ySemPXGO5xT86AvfUHBQi3k0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joseph, Kees, On 5/12/23 00:52, Joseph Myers wrote: > On Thu, 11 May 2023, Kees Cook via Gcc wrote: >=20 >> Okay, understood. If this is a C-only thing, we can ignore the C++ >> impact. >=20 > We're a lot more careful lately in WG14 about checking for C++=20 > 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= =20 > empty types; it would need careful consideration in the liaison group. >=20 >> 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 ne= ed >> special handling in this regard? >=20 > "including a pointer to an object and a subobject at its beginning" and= =20 > "one is a pointer to one past the end of one array object and the other= is=20 > a pointer to the start of a different array object that happens to=20 > immediately follow the first array object in the address space" are bot= h=20 > cases included in the semantics for comparison operators. If you allow= =20 > zero-size objects you get more special cases there (and quite possibly = > affect optimizations based on points-to analysis that can determine=20 > pointers are based on different objects, if an object is not known at=20 > compile time to have nonzero size). Since GNU C already supports empty structs, how about allowing that in GC= C with no intention of adding it to ISO C? We'll see how good it behaves i= n GCC, and if so suggest it for inclusion in the standard. Why should GNU C, which allows empty structures, and de facto supports flexible arrays in empty structs and in unions (via the empty preceeding struct and the wrapper struct tricks, as the kernel does), shouldn't support them officially without tricks? Apart from violating artificial rules that disallow that use of flexible arrays, I believe the example program I provided in the first post doesn't violate aliasing rules or other similar rules that would result in optimization conflicts. Does it? About zero-sized types, a union consisting of only flexible-array members= would effectively be a zero-sized type, so GCC should have similar issues= having this in unions and in empty structs. So far, I don't see GCC complaining about such horrible thing as an array of empty structs: $ cat arr.c #include struct s {}; struct s x[10]; int main(void) { printf("x: %zu, %p\n", sizeof(x), &x); printf("x[3]: %zu, %p\n", sizeof(x[3]), &x[3]); } $ gcc-13 arr.c -Wall -Wextra $ ./a.out=20 x: 0, 0x55c5f6d72019 x[3]: 0, 0x55c5f6d72019 So, in GNU C land, I think it is reasonable to add this feature. Cheers, Alex --=20 GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5 --------------ySemPXGO5xT86AvfUHBQi3k0-- --------------Fe8uTpjyiA6kjMm0Y7SKYAhS Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmRdh2gACgkQnowa+77/ 2zK8WBAAhpZgIr8yTkaVcqMcSO4S3y9uvA7cbDNeIFufkPYpuRubBz65UiKz4TPv ECnyj63LI6hWi+2Y9Hf90eMMGpln4ouRYdBhz4JWB6ooi1dYJLJ35oDyoRilJxY6 WelS6mXn5HIOupigM0lLlVrNJeaPjx9RSmghfWAC1MZkOP3YBxuWmY+7RYKQyIXQ Qbu5ZyQLCRf9bDtGjvnsaDa2giiN55t+Kz0FPQ2lj55ba9tF3RPK2B8f6OAYnBId qoIOe83h9WOVpF4SG2X4oiFBi9afOYjXJo1t3eHH7fNV9t0mqblOIqZ1cAsMdto7 3ZOuqDoZ0dQMaQ7r4JDMkiaMw1svSSq1g2Atejw7fdCcHCEYeXph6za1J30ANE28 H84uAfRVVVC/nXSkEjbSNxm67DIrwpyS9urYrNpdRWn2uf3XP9CYb5e4FY1/MsGb XBWflwYL7YcJJjzneqDRjP8Wnm07K9X+C+o0uf5uDS1g+BOqy6e58UDGmsr1NrJM pGY6CK02SV7xNrFPHQNsabf4CVl/nrermEMHVfLCbzYSF228DqrGvU5RTZweFZVS k3qQ9HAIR+bWvIBVjwx10Z9SyRTmgH2vvN8JyTWWRFUZvLEXynd1S8HHny/Jpvbx M2kPO/uZvyGsxbdVuW14jrz2tTTjacz/QSVNnUxbwoQGBGzyGe4= =J8t9 -----END PGP SIGNATURE----- --------------Fe8uTpjyiA6kjMm0Y7SKYAhS--