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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2994 invoked from network); 27 Aug 2020 09:28:16 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Aug 2020 09:28:16 -0000 Received: (qmail 9811 invoked by uid 550); 27 Aug 2020 09:28: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 9793 invoked from network); 27 Aug 2020 09:28:12 -0000 X-IronPort-AV: E=Sophos;i="5.76,359,1592863200"; d="scan'208";a="464915162" Date: Thu, 27 Aug 2020 11:27:59 +0200 From: Jens Gustedt To: musl@lists.openwall.com Message-ID: <20200827112759.7e04abd3@inria.fr> In-Reply-To: <20200824161400.GG3265@brightrain.aerifal.cx> References: <20200823102439.2bbaffb5@inria.fr> <20200824161400.GG3265@brightrain.aerifal.cx> Organization: inria.fr X-Mailer: Claws Mail 3.17.5git22 (GTK+ 2.24.32; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/u86/_lSl8qF+8tXhwUZx0B8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] direct coding of asctime_r --Sig_/u86/_lSl8qF+8tXhwUZx0B8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Rich, on Mon, 24 Aug 2020 12:14:00 -0400 you (Rich Felker ) wrote: > I'm not *strongly* opposed to this, but my reasoning is fairly much in > line with the POSIX side, that these interfaces are legacy/deprecated, > and in general musl practice is to choose maximum simplicity over > size/performance optimality for deprecated/legacy or junk interfaces. >=20 > In particular, asctime[_r] formats dates in a legacy US format, > whereas modern applications should be using either ISO date format or > a locale-specific format. But which is also a format used by the language itself (or refered to) by `__TIME__` and similar macros. > Note that ISO C specifies asctime in terms of a particular printf > format string, meaning the results are well-defined for any values > that don't overflow the specified buffer, even if they are somewhat > nonsensical. I don't think so. The general rules for valid arguments to C library functions always apply, so according to 7.1.4 calls to the functions with values that are outside the specified ranges for the type have UB. In the header the only exception from this rule seems to be `mktime`, which makes such exceptions explicit and says how the argument is normalized if it is not in the ranges as specified. The sample code that I posted does range checks with simple means that never results in unbounded UB and always returns a string that is null terminated. I would think that this is reasonable behavior. Jens --=20 :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: --Sig_/u86/_lSl8qF+8tXhwUZx0B8 Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCX0d8nwAKCRAP0+hp2tU3 4pVRAKCLHZ5Dprlb+esKIYWGzSsgJz+3RgCdEuqMA/NmO+1ckV+ZSGcGne/UcfA= =l+7W -----END PGP SIGNATURE----- --Sig_/u86/_lSl8qF+8tXhwUZx0B8--