From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 7ec474a5 for ; Mon, 24 Dec 2018 12:58:07 +0000 (UTC) Received: (qmail 5977 invoked by alias); 24 Dec 2018 12:57:48 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 43937 Received: (qmail 6395 invoked by uid 1010); 24 Dec 2018 12:57:48 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.100.2/25112. spamassassin: 3.4.2. Clear:RC:0(66.111.4.25):SA:0(-2.6/5.0):. Processed in 5.608119 secs); 24 Dec 2018 12:57:48 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:references:in-reply-to :date:subject; s=fm2; bh=JkS9XHVEzUnVT9bGzo2uR//6ZfZeXTzs6kUCfwe gaPw=; b=cOQQXGNn9YjC/09Tdatz3IE9dq6xpPIzaoXkxnULoEzYV1pQ92T7FuK u/u7mkNeeCak0Q/dp5xcoivx0xFlBIhn/hGBgL7sxoYm5aEJbb6lgrx+1y0Mrk6J jDnx+vjbomTmTEkUBLyiJUC/T9acJ4y7ZfBfv2MbKFuYjq/+2MYSt7nVUOLD8Ooz AW3IuRSfBZFxlFfPYr5wfwWhp3skCCV2kODvNr7OY+UZzVyf9UCgWhDmXal1xgFS 9xeCkV3jkunUZErlB9KPVEF2w1rwMGuIadx2v+YGudKYzml3RhtDKK6puQAUijKF EWSgWvLERMQUyJ4Jbs8/w8ANlTy1s7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=JkS9XHVEzUnVT9bGzo2uR//6ZfZeXTzs6kUCfwega Pw=; b=HEgGHwy/QEhFY8k0dNpGAjfF/2sGDc++CNsrAt3LQVxltQj1FcvxgfeZR nAuZXKzyTCcXT5sXvIJ++6wIYipb+BD0W1e3t58IDtKOp1aPt5v5DvoOB1RAnqGP XaRBrFROoDqO3/FsTJfPIbEqAKr5/c8yU/LB71IUf1ENcCCEuKMJadhVXxTBFhzs 9UsKaext5MjP3ubuq2FNphVmA4SfX6X+vyxqFbbHA5h4uoHnQOzEqzJlIhk5q0yV YLTmBHE0SwVHI3H5fBwtAZmWc0AfMWD2OisPppxB7YpFOASZyrxF/mEY0zpResPr R6zkGBADKXJXm1lphypwKL0DXoCNw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudekuddggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkhffvggfgtg fofhgjfffusehtqhertdertdejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceo ugdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvqeenucfrrghrrghmpehmrghilh hfrhhomhepugdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvnecuvehluhhsthgv rhfuihiivgeptd X-ME-Proxy: Message-Id: <1545655545.1499531.1617344072.151563DD@webmail.messagingengine.com> From: Daniel Shahaf To: dana , Zsh workers MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2f590f9a References: <20181224054021.GK1941@sym.noone.org> <20181224071421.GL1941@sym.noone.org> In-Reply-To: Date: Mon, 24 Dec 2018 12:45:45 +0000 Subject: Re: [PATCH] ztrftime(): Fix truncation for %. dana wrote on Mon, 24 Dec 2018 03:16 -0600: > Not directly related, but in reviewing workers/43932 further i found that= the > way ztrftime() handles truncation for %. is problematic: >=20 > % strftime '%s.%9.' $EPOCHSECONDS $(( 999_999_999 )) > 1545638724.999999999 > % strftime '%s.%6.' $EPOCHSECONDS $(( 999_999_000 )) > 1545638984.999999 > % strftime '%s.%6.' $EPOCHSECONDS $(( 999_999_999 )) > 1545638724.100000 That's a very odd sequence of $EPOCHSECONDS values. :P Also, in (unpatched) master: % strftime '[%3.]' 123456789 [000] % strftime '[%s][%3.]' 0 123456789 [0][124] %=20 Shouldn't the former print [124]? > I'm not very good at maths =E2=80=94 is there a reason it shouldn't just = be a straight > power-of-ten division like this? Using straight division likes this makes it do truncation; in the code before this patch, the +8 makes it so nsec=3D11152 would print '1116' but nsec=3D11151 would print '1115'. (The +8 should probably be +5 --- half the radix.) 999999999 is an edge case since it rounds up "to the next second". > +++ b/Src/utils.c > @@ -3340,9 +3340,8 @@ morefmt: > digs =3D 9; > if (digs < 9) { > int trunc; > - for (trunc =3D 8 - digs; trunc; trunc--) > + for (trunc =3D 9 - digs; trunc; trunc--) > nsec /=3D 10; > - nsec =3D (nsec + 8) / 10; > } > sprintf(buf, "%0*ld", digs, nsec); > buf +=3D digs;