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=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 9F0DA23202 for ; Tue, 19 Mar 2024 01:02:41 +0100 (CET) Received: (qmail 8144 invoked by uid 550); 18 Mar 2024 23:58:12 -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 7618 invoked from network); 18 Mar 2024 23:57:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710806513; x=1711411313; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lq2X2zqzUzgDa1aWn9fYWKrPHjiAH37FVDKNunk63jY=; b=IH5mHmB6CUK+YPERdeJ+CK7KdnbuERk+Y6wjEgegrk26aFqYeyLAO9sTCLnGn125wG 8emt6JBxyZ7J7su63buK2vSMEfnqfEjfMAfC7Q0OvD/nciBThV0BlgnvbvEd4+rL9RKR 3ZAvpUl//iBqHjPj1RJWnfXyK12CyGiW0ux6e7O30Thb6Y0yODmpNzvX69urQ3ZSimMi q6uJVNs9XJj4m5aRbO7AA6QXJnfyRFXI6mz8tq5sVg0w9VMJqRizM0vhP37OCIN7H7HF bJW53osDWEqiqZXO83cOzAOc1oMPfJ1lGo3Z1pe0pO+hM8gGrOSheqIQhZgi9lxQw07/ 2l7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710806513; x=1711411313; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lq2X2zqzUzgDa1aWn9fYWKrPHjiAH37FVDKNunk63jY=; b=Xcvu4KkpOKW0Cplo2LTrX6tu9PV2HMMdxzPUPPFg0wSgA7rIrpVPUKpFhFzYIInaXq Kahy6oCJ+u7XHwk+H5k0Npb6DQKP/U4yw4qQn1k28OJRPnm1BBDvG5Dx7tE9OVbrOz+C QHxCmIx9s7Kp28bNimt4BCzuG1/yi8yQw1x4p2667oRF7K4a4dhhloZM75E51dn4OYO+ jAYYwaEesyID1yg4g9rOXwow9w6kgV9Fi9o2gOIxFLf6ZMkFJl13VmCcBLbi2GS+DgRJ k83NsvO1xLCm1LmnIK2I1k/AyEzP9ih7FMABAids1kqLPXJDjIffhGdijsLyibIsCF00 Ackg== X-Gm-Message-State: AOJu0YwFc9o4PtOuMGwgAj63OyjipJBrZ35FcEo1Q3vOgodbO9hiK5ku qEfSZBO73o1W89JXtgECQwQs4wNmtba3MP+UeY9paURRcwDE/T1bA+59LO3OPIa4tvf785AkefV 4jFOdtGCk68Wgt2ohcrYi/vXdQTE= X-Google-Smtp-Source: AGHT+IEWOfNyNaSoY3IdGE8cPSF+Glz7oNRn0mHJbLHKpl2eoEsxAXnabB/5iZpOgWmNjQs7gFqZDNsKMYm4pk4SzHQ= X-Received: by 2002:a2e:7d0b:0:b0:2d4:3078:ef3d with SMTP id y11-20020a2e7d0b000000b002d43078ef3dmr6939973ljc.1.1710806512885; Mon, 18 Mar 2024 17:01:52 -0700 (PDT) MIME-Version: 1.0 References: <20240318213441.GH4163@brightrain.aerifal.cx> <627epdel4gidvu46u5ua2mclieqy3wwqbs7sxjgtgrsmkvn4up@ehu5ru6micnr> In-Reply-To: <627epdel4gidvu46u5ua2mclieqy3wwqbs7sxjgtgrsmkvn4up@ehu5ru6micnr> From: Mike Cui Date: Mon, 18 Mar 2024 17:01:41 -0700 Message-ID: To: NRK Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000007ae84a0613f82e3b" Subject: Re: [musl] Potential bug in __res_msend_rc() wrt to union initialization. --0000000000007ae84a0613f82e3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah I also just went over the C99 spec as well, section 6.7.8, and I have to agree with clang developer's interpretation, that "{ 0 }" only initializes the first member of the union. "{ }" apparently is added in C23 as the "universal zero initializer". So changing the order moving sin6 up is the only way to be C99 conformant. On Mon, Mar 18, 2024 at 3:22=E2=80=AFPM NRK wrote: > On Mon, Mar 18, 2024 at 05:34:42PM -0400, Rich Felker wrote: > > If the clang interpretation is going to be this, we can just reorder > > the union members so that the largest one is first. > > Another option is to utilize implicit static initializer rules: > > | if it is a union, the first named member is initialized (recursively) > | according to these rules, and any padding is initialized to zero bits; > > So something like: > > static union u zero; > union u u =3D zero; > > Though, the "padding bits" part was added in C11 and wasn't present in > C99 in case you want to be pedantic about C99 conformance. > > - NRK > --0000000000007ae84a0613f82e3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah I also just went over the C99 spec as well, section 6= .7.8, and I have to agree with clang developer's interpretation, that &= quot;{ 0 }"
only initializes the first member of the union.
<= div>
"{ }" apparently is added in C23 as the "= universal zero initializer". So changing the order moving sin6 up is t= he only way to be C99 conformant.

On Mon, Mar 18, 2024 at 3:22=E2=80= =AFPM NRK <nrk@disroot.org> wr= ote:
On Mon, Mar= 18, 2024 at 05:34:42PM -0400, Rich Felker wrote:
> If the clang interpretation is going to be this, we can just reorder > the union members so that the largest one is first.

Another option is to utilize implicit static initializer rules:

| if it is a union, the first named member is initialized (recursively)
| according to these rules, and any padding is initialized to zero bits;
So something like:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 static union u zero;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 union u u =3D zero;

Though, the "padding bits" part was added in C11 and wasn't p= resent in
C99 in case you want to be pedantic about C99 conformance.

- NRK
--0000000000007ae84a0613f82e3b--