From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 4AC1A261D7 for ; Tue, 19 Mar 2024 17:39:44 +0100 (CET) Received: (qmail 1061 invoked by uid 550); 19 Mar 2024 16:35:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1029 invoked from network); 19 Mar 2024 16:35:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=nIExRjfE+QtdjhnYzt1VVCtog/bdS1qmNzfIR1O+W/4=; b=W3twwcCT8t2lGtWdibmib4jCp6mBfRBGX+4Lm9k/3YQO1fi1UmNXz7ED UccNEN0Sd90vl+TPRKiNVTlMQ+ZqDslykCnfaAhjUqammQQPtFu0q2ibr jM+K0NK5KOr7FXSC6sYjv4DsQQKyalFksY7gF8AJGUUpbVKe53FbL0Tqa E=; Authentication-Results: mail2-relais-roc.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=jens.gustedt@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="6.07,137,1708383600"; d="scan'208";a="157455900" Date: Tue, 19 Mar 2024 17:39:30 +0100 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Rich Felker Cc: musl@lists.openwall.com, Mike Cui , NRK Message-ID: <20240319173930.57b8eb30@inria.fr> In-Reply-To: <20240319160832.GL4163@brightrain.aerifal.cx> References: <20240318213441.GH4163@brightrain.aerifal.cx> <627epdel4gidvu46u5ua2mclieqy3wwqbs7sxjgtgrsmkvn4up@ehu5ru6micnr> <20240319131833.GI4163@brightrain.aerifal.cx> <20240319154222.GK4163@brightrain.aerifal.cx> <20240319160832.GL4163@brightrain.aerifal.cx> Organization: inria.fr X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Potential bug in __res_msend_rc() wrt to union initialization. Hi, actually the introduction of `{}` versus `{0}` in C23 was not meant to provide any difference in semantics, just to make the syntax nicer and consistent with C++. on Tue, 19 Mar 2024 12:08:32 -0400 you (Rich Felker ) wrote: > On Tue, Mar 19, 2024 at 08:55:22AM -0700, Mike Cui wrote: > > On Tue, Mar 19, 2024 at 8:42=E2=80=AFAM Rich Felker w= rote: > > =20 > > > On Tue, Mar 19, 2024 at 08:04:31AM -0700, Mike Cui wrote: =20 > [...] =20 > [...] =20 > [...] =20 > [...] =20 > [...] =20 > [...] =20 > [...] =20 > > > types. > > > > > > No, the part below that you didn't reply to covers unions: > > > > > > =20 > > The full 6.7.9 =C2=B610: > >=20 > > 10 If an object that has automatic storage duration is not > > initialized explicitly, its value is indeterminate. If an object > > that has static or thread storage duration is not initialized > > explicitly, then: > > - if it has pointer type, it is initialized to a null pointer; > > - if it has arithmetic type, it is initialized to (positive or > > unsigned) zero; > > - if it is an aggregate, every member is initialized (recursively) > > according to these rules, and any padding is initialized to zero > > bits; > > - if it is a union, the first named member is initialized > > (recursively) according to these rules, and any padding is > > initialized to zero bits; > >=20 > > The second part that you quoted applies to "static or thread storage > > duration". The first sentence specifically says that anything not > > initialized is indeterminate. > > The only other paragraph which invokes 6.7.9 p10 is 6.7.9p21, which > > also does not apply to unions. (p21 ensures that the "ns" array of > > unions in the code would be zeroed out, but not the "sa" which a > > single union allocated on the stack.) =20 >=20 > =C2=B619 says: >=20 > "all subobjects that are not initialized explicitly shall be > initialized implicitly the same as objects that have static > storage duration." >=20 > The term "subobject" does not seem to be defined, so there's some > ambiguity, but I would read =C2=B619 as applying the above text about > static unions to automatic ones. >=20 > In any case, what clang wants to do here seems like a big gratuitous > footgun. We'll make the code in musl safe against this but I suspect > it will have lots of bad effects elsewhere... To avoid such differences in interpretation, the simplest solution seems to be to always put the biggest union member first, or to even add an artificial first one `char [size-of-the-union] __dummy;`, such that this is always 0-byte initialized if there is any initialization at all. J=E2=82=91=E2=82=99=E2=82=9B --=20 :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Universit=C3=A9 de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: :: :::::::::::::::::::::::::::::::::::: =E2=98=8E +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::