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_INVALID,DKIM_SIGNED, 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 0BB3C22599 for ; Wed, 20 Mar 2024 08:43:08 +0100 (CET) Received: (qmail 24254 invoked by uid 550); 20 Mar 2024 07:38:35 -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 24215 invoked from network); 20 Mar 2024 07:38:35 -0000 X-Env-Mailfrom: aaron_ng@inode.at X-Env-Rcptto: musl@lists.openwall.com X-SourceIP: 85.127.183.170 X-CNFS-Analysis: v=2.4 cv=Jv5Sr94C c=1 sm=1 tr=0 ts=65fa937e a=EGcOpCTuptRmag7BTP1Y/Q==:117 a=EGcOpCTuptRmag7BTP1Y/Q==:17 a=IkcTkHD0fZMA:10 a=b4LDLZbEAAAA:8 a=3zseGSVViKokPll_3iwA:9 a=QEXdDO2ut3YA:10 a=20T61YgZp4ItGotXEy2O:22 X-Authenticated-Sender: aaron_ng@inode.at DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=inode.at; s=201801custpemceu; t=1710920574; bh=IzJOQrZHt9MM3d7AEb7FIS/uW/uaWyUn4EMi8J6YQEg=; h=Date:Subject:To:References:From:Cc:In-Reply-To; b=32GZ5vbZ8Wv+frpBzfSFCxLDMrTBib4SCFJyVaWQy1jbTLqNljGEpyALE6Ws7oMHe QJMGGw9Ix3AtS2wZ2hmKu09lLckBbvpOqW6OGWj5+wlNeD1JLetRcnNQ5rAPcJKfhV +zDxtPqwj3LhI22qJFEVUD/i3MRxRFWzPoZhmr1u3/p3Yh2vlbgGtZtNqtG6DgVPld 6CFObbeKhRkCHRCMDbkkYWySL6TfMzvU2eFmCHrU1SbfWifQP82HfrPxnUW2YgGnK5 yhYqp/7ll5URPMufK5FNcNpAqsYLb/pmyOIsdjOeYsRTcu4m+PR5mz8zAmAkelF85k 9xkBxyoZNg3eQ== Message-ID: <71bbc801-cc8a-422b-9db8-3c2029b9b99c@inode.at> Date: Wed, 20 Mar 2024 08:42:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Rich Felker References: <1ad1a194-f2f5-4ae1-9686-67961086e605@inode.at> <20240319145026.34c1a068@inria.fr> <20240319140213.GJ4163@brightrain.aerifal.cx> <20240319161925.GM4163@brightrain.aerifal.cx> Content-Language: en-US, de-DE From: Aaron Peter Bachmann Cc: musl@lists.openwall.com In-Reply-To: <20240319161925.GM4163@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfHpb0vna3X51HTL/U4ZWZ/kSXZHDwCo5U0ChSiieGrgYdE00WFrkaE8J2ahcLD1Pkd7uJAk1O4nhQycGHyn/eb4Hc73muIm3hNScHqMuUNQjxjvnFP+j KskRvW91WlzMyuEpq+AjTQgU3sQZLkeRZqNh90ddMKH2cE0qM70WyDQCVh8VQlwhVUFpDEmsWa91Keox3szu4WuQQfOoIAa6vpcVJbXDVBYLFP3nBW1D34W0 Subject: [musl] Re: Potential bug in __res_msend_rc() wrt to union, initialization. On 19 Mar 2024 17:36:41 -0400, Rich Felker wrote: > > > 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++. > > > > Regardless of what the intention was, the reality is that it *does* have > > semantic difference. Specifically, empty initialization `{}` benefits > > from the default initialization rules, which specify zero-ing out the > > padding bits whereas `{0}` doesn't guarantee that. > > That's simply not true. There is no difference in the rules as > specified by the standard. There is: Before C23: { } was not mentioned in the std so it was implicitly undefined. {0} was defined. => This is a difference. C23: We can look at n3096: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf Later versions not generally available have - to the best of my knowledge - not changed in regard of whet we are discussing. 6.7.10 p10, p11, ...: 10 Except where explicitly stated otherwise, for the purposes of this subclause unnamed members of objects of structure and union type do not participate in initialization. Unnamed members of structure objects have indeterminate representation even after initialization. 11 If an object that has automatic storage duration is not initialized explicitly, its representation is indeterminate. If an object that has static or thread storage duration is not initialized explicitly, or any object is initialized with an empty initializer, then it is subject to default initialization, which initializes an object as follows: ... For me it reads that when the empty initializer {} is not used, we have default initialization only for memory with static and thread local storage duration, but not for automatic storage duration. This affects the padding. => This is a difference. The empty initializer can be used for VLAs. => This is a difference. But certainly not one we are discussing. But it does not matter for musl, as it does not use C23 and it could not reasonably do so. The fact that compilers implementing {} before C23 could not in advance see what C23 would say does not help either. It will take some time before we can benefit from the stronger guarantees C23 provides via {}. And I would also like to add: If no difference was intended, as we know from Jens, there had better be no difference. Regards Aaron Peter Bachmann