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 F366122D53 for ; Tue, 19 Mar 2024 16:38:40 +0100 (CET) Received: (qmail 30594 invoked by uid 550); 19 Mar 2024 15:34:10 -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 11498 invoked from network); 19 Mar 2024 15:00:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710860684; x=1711465484; 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=Zx5NzaN53cPi6tfGNgz+lFkvw0BoaO8spt+nTZtf7ww=; b=D45ONJtYHcIXDd+wQkIoRy7cP2CFCtz0L2iBtbbFeycHiT+0WSJip1eRXL9CH6KREm 5nBCTVnUJWdelvNaz9quFTtr8rTnUFn9DgZtdVRUtFCwYV1R4RfSvtFX+8ic6I4zVngj nUNPER0h/GbO0rQNkXiPYoNeaH0WeibSsVom4nCSXNFS709+nQcKw5Kdi92To3L3CyA9 DavKKPKaNIgyVZM/fMYAGvKqKdd9EGp68Wwoa41jO6bzbHoXic7xflfLmLWR+F3o/E3K g/z8Mam6YvzWgJaX2vd9cMAW52ttXkwcBQcV4ZgZHehrGrdTNyqL61+vz8hgwaWqPIGX QhYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710860684; x=1711465484; 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=Zx5NzaN53cPi6tfGNgz+lFkvw0BoaO8spt+nTZtf7ww=; b=R32bT6D8RK0bju6Z209DRUupKh0g3GQPUmDlUuiEF9knISw5O5/dzd9p41rVACaAHB L4mkM7UA81QxV7/28osQ4KVeLqQU1hR5o7C3G17LBM8d+aHa0FDLQqExjlcWh7VH9fFC Yp8dHd2oSCSu452OC7tccC7EERex9IWL9/mHISGx8c9TjMRinvUBWqGRVX4ben4rgO3G biKJZuLAYbbZhmqG6TXdATMkAnpT59lkXSQE9LEfCu9CDtnKKVJ8oJ3aYtqtClgMtoSw 2DnrFozTi2kQ9ZqdHbE8cG9NEn/P7QwtiCAdrB16bNl1rD3JDTR2WKBMc/xWEX0R0w0I skEQ== X-Forwarded-Encrypted: i=1; AJvYcCVbrgXlacUAExQq9jCS929OQn1hCZibpFmlUGDinsUNCRNdgO5kN9Nq7tvQWx9UWQa3qudI6G7OJVjZ2q15Z4bORQqXR1gTJA== X-Gm-Message-State: AOJu0YzwKAm/DosZEDh6z3O2gV2BQ7wRZr1jeHl2o6KspOCCAow5f06m zSJIWEPLQCYRpvO9Dri3ZsejCs4agm2ThnSSPWbUG2iCYjlmSZaOF9n2VNMnQA+0FglRXR6lNZx t6GLjsP9E0pSeBkyzIwfZw39pfAU= X-Google-Smtp-Source: AGHT+IGZXC+tnWVW1tE8RmCvyMBXBurW0Sr0AJrWDSf9zuZyYHKSOhuwYwGam6ebYLAPAJPKejAmok1w9VDLiyOrSqI= X-Received: by 2002:a05:651c:786:b0:2d4:843:54e0 with SMTP id g6-20020a05651c078600b002d4084354e0mr7368938lje.43.1710860683967; Tue, 19 Mar 2024 08:04:43 -0700 (PDT) MIME-Version: 1.0 References: <20240318213441.GH4163@brightrain.aerifal.cx> <627epdel4gidvu46u5ua2mclieqy3wwqbs7sxjgtgrsmkvn4up@ehu5ru6micnr> <20240319131833.GI4163@brightrain.aerifal.cx> In-Reply-To: <20240319131833.GI4163@brightrain.aerifal.cx> From: Mike Cui Date: Tue, 19 Mar 2024 08:04:31 -0700 Message-ID: To: Rich Felker Cc: NRK , musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000005406ba061404cb86" Subject: Re: [musl] Potential bug in __res_msend_rc() wrt to union initialization. --0000000000005406ba061404cb86 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 19, 2024 at 6:18=E2=80=AFAM Rich Felker wrote= : > On Mon, Mar 18, 2024 at 05:01:41PM -0700, Mike Cui wrote: > > 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. > > There is no such thing as "only initializes [part]" in the C language. > The { 0 } *only provides a value for* the first member. The question > is about what happens to parts of the object for which the initializer > did not "provide a value". However, the C99 standard does not clearly > describe how the bits of a union that are not part of the member for > which a value is provided (usually the first, unless a designated > initializer is used) are filled on initialization. > > You are referring to this paragraph? 6.7.9 =C2=B621 If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration. Folks on the LLVM discourse pointed out this paragraph does not apply to unions, since unions are not "aggegates" according to the definition in 6.2.5p21: 21. Arithmetic types and pointer types are collectively called scalar types. Array and structure types are collectively called *aggregate* types. > C11 adds (in 6.7.9 =C2=B610): > > "if it is a union, the first named member is initialized > (recursively) according to these rules, and any padding is > initialized to zero bits;" > > where C99 just had (6.7.8): > > "if it is a union, the first named member is initialized > (recursively) according to these rules." > > So I think C11 and later actually require the full zero > initialization of all bits, and clang is just wrong. > > > "{ }" apparently is added in C23 as the "universal zero initializer". S= o > > changing the order moving sin6 up is the only way to be C99 conformant. > > Indeed since at the source level we just depend on C99 not C11, this > should be changed. But clang needs to be fixed too. > > Rich > --0000000000005406ba061404cb86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Mar 19, 2024 at 6:18=E2=80=AF= AM Rich Felker <dalias@libc.org&g= t; wrote:
On Mon= , Mar 18, 2024 at 05:01:41PM -0700, Mike Cui wrote:
> 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 }&q= uot;
> only initializes the first member of the union.

There is no such thing as "only initializes [part]" in the C lang= uage.
The { 0 } *only provides a value for* the first member. The question
is about what happens to parts of the object for which the initializer
did not "provide a value". However, the C99 standard does not cle= arly
describe how the bits of a union that are not part of the member for
which a value is provided (usually the first, unless a designated
initializer is used) are filled on initialization.

You are referring to this paragraph?

6.7.9 =C2=B621
If there are fewer initializers in a = brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize= an array of known size than there are elements in the array, the remainder of the aggregate s= hall be initialized implicitly the same as objects that have static storage duratio= n.

Folks on the LLVM discourse pointed out thi= s paragraph does not apply to unions, since unions are not "aggegates&= quot; according to the definition in 6.2.5p21:
21. Arithmetic types and = pointer types are collectively called scalar types. Array and structure types are collectively called *aggregate* types.
= =C2=A0
C11 adds (in 6.7.9 =C2=B610):

=C2=A0 =C2=A0 "if it is a union, the first named member is initialized=
=C2=A0 =C2=A0 (recursively) according to these rules, and any padding is =C2=A0 =C2=A0 initialized to zero bits;"

where C99 just had (6.7.8):

=C2=A0 =C2=A0 "if it is a union, the first named member is initialized=
=C2=A0 =C2=A0 (recursively) according to these rules."

So I think C11 and later actually require the full zero
initialization of all bits, and clang is just wrong.

> "{ }" 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= .

Indeed since at the source level we just depend on C99 not C11, this
should be changed. But clang needs to be fixed too.

Rich
--0000000000005406ba061404cb86--