From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-20681-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,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 4841B21D58
	for <ml@inbox.vuxu.org>; Thu, 21 Mar 2024 17:53:47 +0100 (CET)
Received: (qmail 31850 invoked by uid 550); 21 Mar 2024 16:49:11 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 31818 invoked from network); 21 Mar 2024 16:49:11 -0000
Date: Thu, 21 Mar 2024 16:41:58 +0000 (UTC)
From: Thorsten Glaser <tg@mirbsd.de>
X-X-Sender: tg@herc.mirbsd.org
To: musl@lists.openwall.com
In-Reply-To: <20240321115806.511a81cc@inria.fr>
Message-ID: <Pine.BSM.4.64L.2403211637580.19384@herc.mirbsd.org>
References: <CAMbjb11yqF2fzp4bR3k4_=jp_bc7cNP15vJecEvNBGHgeXL5nw@mail.gmail.com>
 <20240318213441.GH4163@brightrain.aerifal.cx>
 <627epdel4gidvu46u5ua2mclieqy3wwqbs7sxjgtgrsmkvn4up@ehu5ru6micnr>
 <CAMbjb12WQL+DQSP0xXy84fNTEGTbE2DX1=oX-Wc_s2wyRAxypg@mail.gmail.com>
 <20240319131833.GI4163@brightrain.aerifal.cx>
 <CAMbjb13m8_+FHRfOV5M3ff6nf1iT=2Rk4mzom55FZArqAYUEdA@mail.gmail.com>
 <20240319154222.GK4163@brightrain.aerifal.cx>
 <CAMbjb13VDdiGWsx0jHx5GniNp9OyMiM0LL0muXsqeK+ZYdoLJQ@mail.gmail.com>
 <20240319160832.GL4163@brightrain.aerifal.cx> <20240319173930.57b8eb30@inria.fr>
 <Pine.BSM.4.64L.2403192046020.21682@herc.mirbsd.org> <20240321115806.511a81cc@inria.fr>
Content-Language: de-Zsym-DE-1901-u-em-text-rg-denw-tz-utc, en-Zsym-GB-u-cu-eur-em-text-fw-mon-hc-h23-ms-metric-mu-celsius-rg-denw-tz-utc-va-posix
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.

J=E2=82=91=E2=82=99=E2=82=9B Gustedt dixit:

>As soon as you store
>to any member, padding bytes may change to arbitrary values.

Yes, but where is that a problem?

Something like:

union foo {
=09struct bar {
=09=09char *s;
=09=09size_t z;
=09} a;
=09struct baz {
=09=09size_t z;
=09=09char *s;
=09} b;
};

int
somefunc(int mode, char *buf, size_t len, =E2=80=A6)
{
=09union foo u;

=09memset(u, '\0', sizeof(u));
=09/* =E2=80=A6 */
=09if (mode) {
=09=09/* from here on, u is decided to be a */
=09=09u.a.s =3D NULL;
=09} else {
=09=09/* from here on, u is decided to be b */
=09=09u.b.s =3D NULL;
=09}
=09/* =E2=80=A6 some other processing =E2=80=A6 */
=09if (mode) {
=09=09u.a.s =3D buf;
=09=09u.a.z =3D len;
=09} else {
=09=09u.b.s =3D buf;
=09=09u.b.z =3D len;
=09}
=09return (someotherfunc(&u, mode, =E2=80=A6));
}