From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3381 invoked by alias); 27 Feb 2018 16:56:43 -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: 42408 Received: (qmail 3472 invoked by uid 1010); 27 Feb 2018 16:56:43 -0000 X-Qmail-Scanner-Diagnostics: from cventin.lip.ens-lyon.fr by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(140.77.13.17):SA:0(-1.9/5.0):. Processed in 1.910708 secs); 27 Feb 2018 16:56:43 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: vincent@vinc17.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Date: Tue, 27 Feb 2018 17:56:33 +0100 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: inf and nan in arithmetic expansions Message-ID: <20180227165633.GC26037@cventin.lip.ens-lyon.fr> Mail-Followup-To: zsh-workers@zsh.org References: <20180207223051.GA30393@chaz.gmail.com> <4253.1518045946@thecus.kiddle.eu> <1518093995.645366.1263935336.265ED7BF@webmail.messagingengine.com> <17756.1518799875@thecus.kiddle.eu> <20180227130248.GA10630@cventin.lip.ens-lyon.fr> <12828.1519745147@thecus.kiddle.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12828.1519745147@thecus.kiddle.eu> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.9.3+93 (ebd93b50) vl-105418 (2018-02-14) On 2018-02-27 16:25:47 +0100, Oliver Kiddle wrote: > Vincent Lefevre wrote: > > > This is actually system specific. We generate whatever printf(3) > > > generates. Try out Stephane's examples on Solaris and you get Inf and > > > NaN instead. I think I prefer those forms. We can make the printf code > > > detect them and hard code a consistent form so that we are consistent > > > across platforms. > > > > What do you mean by "We generate whatever printf(3) generates."? > > Zsh calls printf(3) to do the work underneath. The following code: > #include > int main() { printf("%g\n", 1e9999); } > Will output "Inf" on Solaris and "inf" on Linux (for glibc at least). > And the zsh printf builtin does likewise on each platform. Solaris is broken. The ISO C99 and C11 standards say: A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity — which style is implementation-defined. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) — which style, and the meaning of any n-char-sequence, is implementation-defined. The F conversion specifier produces INF, INFINITY, or NAN instead of inf, infinity, or nan, respectively. Thus for the above example, the correct outputs are "inf" and "infinity". > > On Debian/unstable: > > > > cventin% echo $((1e9999)) > > inf. > > That trailing . is unrelated. It is added to ensure floating point types > remain floating point which is not applicable to Inf and NaN. OK, so whatever printf(3) generates and a trailing ".". -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)