From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx-2023-1.gwdg.de (mx-2023-1.gwdg.de [134.76.10.21]) by sourceware.org (Postfix) with ESMTPS id 7EAE43885C1B for ; Wed, 19 Jun 2024 19:03:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EAE43885C1B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gwdg.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gwdg.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7EAE43885C1B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=134.76.10.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718823791; cv=none; b=cKK9+yW9Y5qTmwWuUQpof/ym+WnPl/qekJAgqcOUOP+MMb+XblCOFXFwa+LZ30iYYYEUTAEYjPX1gSj5cLshW8pIuHSo4lr1YHOPKqDZUcq7232SgdQwoqtQkZ7YGzoDMh/d5egJrRhDHT2eUZIQWLw5S4XNX1CsHMCKvHREGOI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718823791; c=relaxed/simple; bh=L6lX1xe9T8Caxl9lW832SL2rv3kE/JReut6G7XRxyK8=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=RPTvuY7l9B6lbV4pC6mein+usGmb2vYLqeuDZtIcFKqkIQPeIjTTDUAaEmneLw42EqBVb9lScdaYgiVV1S7uMlmqd9GDkwdKAkNFvdE+twHC+kEBD/ZnwP1Dq2Tt5vJ1uNPfJyVVl9GVYs7ReQKeJnRlgkk+lIAjGVqNp51ytBs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gwdg.de; s=2023-rsa; h=MIME-Version:Content-Transfer-Encoding:Content-Type:References: In-Reply-To:Date:CC:To:From:Subject:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=72hDzBfSDdJY5IB7HnP1PxOvbBQYKme9DLRap+64pNc=; b=IpKNLf+1hQds06ejT0F11y/N5o HmK8MneWOqubIoNmqihiayl59neyFw1IN7WymcTJFk8x/67bm0fBOma6PdThKu5HbzKxjex1srZQR a1TDd5KfjhkH6aEg507QdJbVusE09Vh5sv3aFqBmKfVKvHh+khvl26f1Q1zLLv7lczCh3mzcOF6+i zpTyKJBLFNG0s9Qk9G0ZK2piFy3DSC5Pmz2GPDLMx6eWM0GZ5DeIqsXo+6ohz993YbkENZqNr1QbW to7/Xq6pvpg1ByEUQTpRt44IAcozfG63R0SSzxG5Xye3o6Lrg18b9hRD9NAJvpINoUzvpyGFzy2VH LwpqVmAw==; Received: from xmailer.gwdg.de ([134.76.10.29]:56807) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1sK0aD-00EI15-2g; Wed, 19 Jun 2024 21:03:06 +0200 Received: from mbx19-fmz-06.um.gwdg.de ([10.108.142.65] helo=email.gwdg.de) by mailer.gwdg.de with esmtps (TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (GWDG Mailer) (envelope-from ) id 1sK0aD-000GiX-28; Wed, 19 Jun 2024 21:03:01 +0200 Received: from vra-168-243.tugraz.at (10.250.9.199) by MBX19-FMZ-06.um.gwdg.de (10.108.142.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.2.1544.11; Wed, 19 Jun 2024 21:03:01 +0200 Message-ID: Subject: Re: Union initialization semantics From: Martin Uecker To: Jonathan Wakely , Alexander Monakov CC: Date: Wed, 19 Jun 2024 21:02:59 +0200 In-Reply-To: References: <18671112-7250-d15b-b379-337e40d80317@ispras.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-04.um.gwdg.de (134.76.9.219) To MBX19-FMZ-06.um.gwdg.de (10.108.142.65) X-Virus-Scanned: (clean) by clamav X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,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: Am Mittwoch, dem 19.06.2024 um 13:59 +0100 schrieb Jonathan Wakely via Gcc: > On Wed, 19 Jun 2024 at 11:57, Alexander Monakov wrot= e: > >=20 > > Hello, > >=20 > > I vaguely remember there was a recent, maybe within last two months, di= scussion > > about semantics of union initialization where sizeof(first member) is l= ess than > > sizeof(union). The question was whether it's okay to initialize just th= at first > > member and leave garbage bits in the other, larger, members of the unio= n, like > > in this example: > >=20 > > union A { > > char a; > > long : 0; > > }; > >=20 > > void fn(void *); > >=20 > > void my(void) > > { > > union A a =3D { 0 }; > > fn(&a); > > } > >=20 > > (except in my example there's no other named member, but I think the ex= ample > > in that discussion was less contrived) > >=20 > > Perhaps somebody remembers where it was (I'm thinking Bugzilla) and cou= ld point > > me to it? My attempts to search for it aren't turning anything up so fa= r. >=20 > Somebody asked about this internally at Red Hat recently, and I > responded with this quote from C17 6.2.6.1 p7: > "When a value is stored in a member of an object of union type, the > bytes of the object representation that do not correspond to that > member but do correspond to other members take unspecified values. " >=20 > This looks related too: > https://discourse.llvm.org/t/union-initialization-and-aliasing-clang-18-s= eems-to-miscompile-musl/77724/3 > They don't seem to have found the quote above though. >=20 > I think it got reported to GCC's bugzilla too, I'll see if I can find it = again. >=20 > > If someone knows what semantics GCC implements, that also would be welc= ome. >=20 > GCC seems to initialize the trailing bits, unnecessarily. Note that C23 will require the padding bits to be initialized with zero for default initialization {}. Martin