From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29570 invoked from network); 25 Jun 2023 18:38:20 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 25 Jun 2023 18:38:20 -0000 Received: (qmail 11587 invoked by uid 550); 25 Jun 2023 18:38:16 -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 11549 invoked from network); 25 Jun 2023 18:38:15 -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; bh=ZzNpsj2xdVhLoYaN5pF8jMqGd+kw4wKp57OUeTg3bzI=; b=IK8jjWbEaHYJvCY+0MD4Ea+ICLcfBqnTt097UyjawOPb0KadawiHDjDs 5ZO/NIik9mgQM61Qyk1YSqEGdMygWzefMyfaueTgajxCxEpz17NvCLZiy IVrm7t9bFpo/g0k4jYRCZ7fGvphbPPiOoAH68uWMFQTzt4mjmMxkuwXfb o=; Authentication-Results: mail3-relais-sop.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.01,157,1684792800"; d="scan'208";a="59756205" Date: Sun, 25 Jun 2023 20:38:02 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20230625203802.50bb2228@inria.fr> In-Reply-To: <20230625152443.GQ4163@brightrain.aerifal.cx> References: <20230625094818.5e6b156c@inria.fr> <20230625152443.GQ4163@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: multipart/signed; boundary="Sig_/Qg6cdOB4uSN2ye9hFq_fswJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] C23: other last minute changes --Sig_/Qg6cdOB4uSN2ye9hFq_fswJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rich, on Sun, 25 Jun 2023 11:24:44 -0400 you (Rich Felker ) wrote: > On Sun, Jun 25, 2023 at 09:48:18AM +0200, J=E2=82=91=E2=82=99=E2=82=9B Gu= stedt wrote: > > Hello, > > there were other last minute (in the literal sense of the term) > > changes to C23 that might impact musl. I updated the summary page at > >=20 > > https://gustedt.gitlabpages.inria.fr/c23-library/ > >=20 > > As far as I can see these are > >=20 > > - `PRI` macros for narrow types now have to be exact, musl does > > not seem to conform to this new requirement =20 >=20 > Yes; this probably requires some minor conditional logic for the FAST > cases but otherwise it should be very straightforward to change. It's > not clear to me what the conformance distinction is here, though. Is > it not undefined behavior to pass an argument for %hhd (for example) > whose value is not in the range of a signed char? > Perhaps values in the range of unsigned char are also supposed to be > okay, but should get interpreted as signed? I don't see where printf > is specified to handle arbitrary wrong-type-but-rank-<=3D-int values, > though..? The explicit specifiers now all have phrases such as (the argument will have been promoted according to the integer promotions, but its value shall be converted to signed char or unsigned char before printing); Note the shall, here. AFAIKS musl already satisfies that requirement for the length modifiers for the standard types. The last minute change only concerns the `PRI` macros. Here a not-so-brillant phrase has been added that a conversion to the expected type (so generally `[u]int_leastN_t`) is also expect to happen when using the `PRI` macros. It seems that musl here has no length modifiers for narrow types in the `PRI` macros. I guess that this is relatively easy to fix by adding `__PRI8` and `__PRI16` auxiliary macros. (Maybe the "fast" types need something special?) > > - the `lc` specifier for `printf` does print NUL for a nul > > character, we already talked about this > >=20 > > For the first, a change is conforming to C17 so it can be done > > immediately without problems. The second is in principle a normative > > change in C and in POSIX, but it seems that all other POSIX > > implementations already are doing this, so probably we should just > > fall in line. =20 >=20 > Yes, this change can be made immediately. Since actually adding > single-wchar processing code seems like messy duplication of the code > already in the %ls case, my leaning would be just adding this as > (pseudocode since a new label is needed too): >=20 > case 'C' > + if (!arg.i) goto case 'c'; > wc[0] =3D arg.i; >=20 > > There are also > >=20 > > - `mktime` and `timegm` are not supposed to change `tm_wday` if > > the conversion fails =20 >=20 > My default interpretation (which admittedly we don't *always* follow, > and is difficult or impossible in a few cases) is that, if a function > is specified to modify some pointed-to object on successful > completion, that it's not even allowed to modify it on failure. And > indeed we do not touch *tm until the final success path in > mktime/timegm. great > > - `fputwc` now also sets the error indicator of the stream if an > > encoding error occurs. This was previously already required by > > POSIX. > >=20 > > I don't think that musl has problems here =20 >=20 > That sounds right. I guess fputwc is still unfixed, though? I probably > should have followed up on that from the Austin Group side.. I did not understand all the code, but it looks ok to me. (I miss where `errno` would be set, but this is probably in one of the functions that are called?) 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 :: --Sig_/Qg6cdOB4uSN2ye9hFq_fswJ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCZJiJigAKCRAP0+hp2tU3 4sANAJ0Y39ZKmEu+5sBj3vrDjZWTnw4MqACfSOWauNRIryYRC0KK6kkkt/dD6r8= =6uQ7 -----END PGP SIGNATURE----- --Sig_/Qg6cdOB4uSN2ye9hFq_fswJ--