From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by sourceware.org (Postfix) with ESMTPS id 73E073858CDB for ; Sun, 4 Feb 2024 20:37:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 73E073858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 73E073858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2604:1380:40e1:4800::1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707079073; cv=none; b=Vn7/P+OoK8nU+vs7rea3ECZ/YGCUrlUkMyr9vuIAAAKUgMW87tAgOrAwtaiGKZOjCTWFR7I29/tXWqSCKxWVUex7kU/6gi8pnU2gks4WLZKsKBrWuIyTRUdTpWkqJEJUJMr4Y1h62cAPli0z+tdWS76p3JjTI/H9Ra+H1+qD7EM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707079073; c=relaxed/simple; bh=ogvAgcbfgN8a+X5LdMHR2rfTLIL4EgeQ643crXSMqOE=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=cs6FmBsVoOL+/Hv2mxBnM5zvJkTSCIhAiDdvx6zBUpDbiXoPJdFDY16fsJHRZ4nh3QHQQ5tdon4dUanqGn1HOazokmRngaPbk/hl72frDwUeIwtn+CJy1Rk2UaoEuJNstDSi1y5pEknVrqKSX7Yiy93A4SK1QzE+9UrSYPhmjD0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 0D982CE0AEC; Sun, 4 Feb 2024 20:37:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DF1FC433F1; Sun, 4 Feb 2024 20:37:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707079067; bh=ogvAgcbfgN8a+X5LdMHR2rfTLIL4EgeQ643crXSMqOE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hjF5EIG5SaNk6T6QMCOTrJreeDbts/6nXjBY4kJhZ2F2PnlFqjxv+BjFOXQLsxnln syfM+KZzwzhMHcNdpbngj/6PACzNElYudJabXVOJaBtwWhSjYXs3ho9h6wt6Xk6RSu Z+DZe2cvW3CXFA3h58BpDaN8RSCweMAIos3FAfU8YD7pqZPYeS5aboc4eYzXeXB57f DuiYtd4ghckLUbJmDC34p+sfDyw6vRhJvO78ZlQJv8N7b9lh4XJWo04WZng3iFT1eF sx9lwWY+NuXG5mocQJ24DjktCvbO7DkWeHJmyrTKTXxM2yD1p1bNCjkF6X47pza/W9 rh315sggANAvg== Date: Sun, 4 Feb 2024 21:37:38 +0100 From: Alejandro Colomar To: Amol Surati Cc: gcc-help@gcc.gnu.org Subject: Re: Assignment of union containing const-qualifier member Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Lul7rD+URRoCEV3s" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: --Lul7rD+URRoCEV3s Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Feb 2024 21:37:38 +0100 From: Alejandro Colomar To: Amol Surati Cc: gcc-help@gcc.gnu.org Subject: Re: Assignment of union containing const-qualifier member On Sun, Feb 04, 2024 at 07:40:23PM +0100, Alejandro Colomar wrote: > > It seems that a union only provides a view of the object. The union > > object doesn't automatically become const qualified if a member > > of the union is const-qualified. This seems to be the reason v.w =3D u.w > > works; otherwise, that modification can also be viewed as the > > modification of an object (v.r) defined with a const-qualified type thr= ough > > the use of an lvalue (v.w) with non-const-qualified type - something th= at's > > forbidden by the std. >=20 > Modifying a union via a non-const member is fine in C, I believe. I > think you're creating a new object, and discarding the old one, so you > don't need to care if there was an old object defined via a > const-qualified type. That is, the following code is valid C, AFAIK: >=20 > alx@debian:~/tmp$ cat u.c=20 > union u { > int a; > const int b; > }; >=20 > int > main(void) > { > union u u =3D {.b =3D 42}; >=20 > u.a =3D 7; > return u.b; > } > alx@debian:~/tmp$ gcc-14 -Wall -Wextra u.c=20 > alx@debian:~/tmp$ ./a.out ; echo $? > 7 > alx@debian:~/tmp$ clang-17 -Weverything u.c=20 > alx@debian:~/tmp$ ./a.out ; echo $? > 7 Although I would have doubts about what happens if the union contains an aggregate, and you modify part of it: union u { int a[2]; const int b[2]; }; int main(void) { union u u =3D {.b =3D {42, 13}}; u.a[0] =3D 7; return u.b[0]; } or union u { struct { int a0; int a1; } a; const struct { const int b0; const int b1; } b; }; int main(void) { union u u =3D {.b =3D {42, 13}}; u.a.a0 =3D 7; return u.b.b0; } In these cases, we're mnodifying a const object (.b), via a non-const lvalue (.a.a0, and .a.a1). We're modifying it, because we keep the original value at .b.b1, but the new one at .b.b0, so in this case we can't say it's an entire new object. Is this legal? Both GCC and Clang accept it, but I have doubts. Maybe you could warn if the program sets a union via a const member when there are non-const members, because it seems like something wrong to do. But as long as you don't set the const member, you should be fine according to ISO C. That is, if you initialize the union via .a, then anything is valid, as the object is defined non-const. Have a lovely night, Alex --=20 Looking for a remote C programming job at the moment. --Lul7rD+URRoCEV3s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmW/9ZIACgkQnowa+77/ 2zIRHA//USc9F0aIANkqnV3mde4qQ089Sqf8f5xxKEL6ZfuKszn3rMc/nbeAjDH5 TF/+7AzfH8uwTZK1dIXwCU1b3p4Ta7ny02iEfiH2iUtfkkRSWtT31Ck29d8xAdqC Cyy+N5OM8Rq83enbPxmRwydX+3QW00pgodjVoJ5HGT3SMznDjGMfZatjEFi7jx0Q LFSDpVFGifauaiCW7DJohaD+EscdN2WORKse6EzthUrSyWaM4gO04IL34kOlc9FW aDnL3NA5Bc3OsHXC4b9k+8oKqxDvIilxHxT3dt8LQNvBRA3esRJtwqIobq47TTSG uu0uoKIGmcHZfp320vbl1k+o41/UOUo5h4I2zMeVgZx3PAS8+8DGhl2KBR9M7MlZ 4F+c+K19g8Zi5Cp6yqDtbdnIhhdBmCypYEnmmb6qDn8POgk//6tjltbr2YJfHSeA HDTgpIam+XstdoMi1vA/yE9tqDKVDn7QkbQdmBZhLMEyXKmuhHwt2G/YDKd7kp2b kVyFvFNT0lQMtCYRlmuLuXTe5jbS0v8qc/uBU9AoaYMFBZWuHeccJ606Yi3zpuwX g7krzLhLWWm5dLh1KvfvC9sFkE90HQ8MaWXF/toXB0XWwdG7j0MTOaheeIgep1oo 1NjxR2v1JmT1kmUaqVoikVJCIUjW67pcV9+tvr+0VmouB5BrSQA= =20u5 -----END PGP SIGNATURE----- --Lul7rD+URRoCEV3s--