From owner-freebsd-standards@FreeBSD.ORG Sun Dec 21 21:00:24 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4347682 for ; Sun, 21 Dec 2014 21:00:24 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9952C2DE4 for ; Sun, 21 Dec 2014 21:00:24 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id sBLL0OUf071086 for ; Sun, 21 Dec 2014 21:00:24 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201412212100.sBLL0OUf071086@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-standards@FreeBSD.org Subject: Problem reports for freebsd-standards@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 21 Dec 2014 21:00:24 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Dec 2014 21:00:24 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 164787 | dirfd() function not available when _POSIX_C_SOUR Open | 188036 | mblen(3) in EUC locales causes crash and segmenta Open | 191586 | FreeBSD doesn't validate negative edgecases in bi 3 problems total for which you should take action. From owner-freebsd-standards@FreeBSD.ORG Wed Dec 24 19:16:10 2014 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A6E89D7 for ; Wed, 24 Dec 2014 19:16:10 +0000 (UTC) Received: from nm17-vm1.bullet.mail.bf1.yahoo.com (nm17-vm1.bullet.mail.bf1.yahoo.com [98.139.213.55]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1ADA64C56 for ; Wed, 24 Dec 2014 19:16:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1419448568; bh=KCnToET7JWG5S/pQhwiXfq+OX0DxAR71v/t7rNx9q2s=; h=Date:From:To:Subject:From:Subject; b=lPp2XZFSJJUlD/lFcl7YcxQlwll4haqeJFVlsLFjJOcoVjEp3I2D/q/Pp37FZYN0oeEqwci3IT83Z3t039F6ldHQB6tb83d5oF25COkGie3bRryHlWx4kOx/rnBxVKSBJLKHBsM6QTom9jmgIygpD3Ycc5Cwf1BHbIfuovZt4GYPR/HKZplq1WvDyCYp5W/gn+7a7DQ6FyxGGZ83frm1Lql0lcMT4M94WExn5xz48dZIQ59a9mVthNixpmdR7UZKWV/MttAg1xA+V2T/UKKIsBdSZCll9ku4e9s6zizRzqwdqCz4pDBRpQqpqW/d5I6ndqLxqHH/zJQxeD3MT5Oggg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=csU3B8vg8cUluY+vbgffPle2D0LbZzX1DzGjJLpcGQUprst6VdgY1QMrlxJHr1aMlbM0ciLbOcuvMEdBSny948SPGkipq3Pwg9l3WqnbfRE78lseOsuCf5HOSGtLIa0TgCvoa59ITU3ySHtTQFeVs+E9oyav1JYgdLMMnuySUl3hkzvjwq45AC329kL//Tccenkczil0gpNUUDwpGHtTnVXr8AYera5uYvlL4OsvGjJ6ewQktnV0TN+XzfF2Y2Myla31EJa8M9zr6KLSKBMCXy3fdJ85xgkVFGJ84kOsSQHK45HNj+auv1DbxGvkCBkGBpbWBGW0RbrJsGImI+GjuQ==; Received: from [66.196.81.172] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 24 Dec 2014 19:16:08 -0000 Received: from [98.139.211.207] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 24 Dec 2014 19:16:08 -0000 Received: from [127.0.0.1] by smtp216.mail.bf1.yahoo.com with NNFMP; 24 Dec 2014 19:16:08 -0000 X-Yahoo-Newman-Id: 434298.58479.bm@smtp216.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6Qzo2wQVM1k0iFyIoESswn4Q2uMBdDAlUM7g._NyMgCwUzT yjJ5cKaWMVl2fvLzcO5TND0TcKrHH.4OFxtQMTn5uq0RNhV32yubg4IYzha2 PAZMH5nGfTkYyf8636_PPjjmumSAdQ7KGm4QiFKq85BX92lDJvE7h0iOnl3g Qz0Me6BhYDevQA9zFQ4AyrQueZPjHzntH5lOh1VmJ3ZKLmnP3.zL_9s27_PS F7P7lGzkG51U8jYS1ysmdzR1HA9MEO3scwt2Ubc9Xpp.NDmbefx9QlXYu4BC Vr7Kev4RW8UAeEiYagRqGA3MJeCfrXn7JypLtvyBEnaj6ILxczR7LCcdvoKJ PNA4lMOQAqLXGAd_RhAVX9QzoburVmPM8fuIzzyNkZG4eX8kC3uY__6drU78 UPRzgeoeviEexjtPdHBG_AZnRQAH.ZGxkTgViFwGTvhhrXc.fumTgH5y3UwF mxkVYkc.6rtwrv7Nc4drVPMztpvAJ8yj.txtHkD1Ke2TPoy9z1OJzRltnj47 Oe6XwDvHLHTPTpGoq67AuaIArY77K5jkV X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <549B1115.8000909@FreeBSD.org> Date: Wed, 24 Dec 2014 14:16:37 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-standards@FreeBSD.org Subject: Does posix say anything about the sign in NaNs ? Content-Type: multipart/mixed; boundary="------------070302050101030406080200" X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 19:16:10 -0000 This is a multi-part message in MIME format. --------------070302050101030406080200 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello; I got the attached patch from OpenBSD. It says: ____ Show the sign for NaN as per POSIX; from Elliott Hughes. ok martynas@, millert@, doug@ ____ I can't find a reference in POSIX documentation to support it though. Anyone has a reason why we shouldn't adopt it, or a reference I can quote on the commit log? Regards, Pedro. ps. Merry Christmas to everyone !! --------------070302050101030406080200 Content-Type: text/x-patch; name="stdio-vfprintf-nan.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="stdio-vfprintf-nan.diff" Index: lib/libc/stdio/vfprintf.c =================================================================== --- lib/libc/stdio/vfprintf.c (revision 276188) +++ lib/libc/stdio/vfprintf.c (working copy) @@ -721,10 +721,9 @@ if (signflag) sign = '-'; if (expt == INT_MAX) { /* inf or nan */ - if (*cp == 'N') { + if (*cp == 'N') cp = (ch >= 'a') ? "nan" : "NAN"; - sign = '\0'; - } else + else cp = (ch >= 'a') ? "inf" : "INF"; size = 3; flags &= ~ZEROPAD; Index: lib/libc/stdio/vfwprintf.c =================================================================== --- lib/libc/stdio/vfwprintf.c (revision 276188) +++ lib/libc/stdio/vfwprintf.c (working copy) @@ -788,10 +788,9 @@ if (signflag) sign = '-'; if (expt == INT_MAX) { /* inf or nan */ - if (*cp == 'N') { + if (*cp == 'N') cp = (ch >= 'a') ? L"nan" : L"NAN"; - sign = '\0'; - } else + else cp = (ch >= 'a') ? L"inf" : L"INF"; size = 3; flags &= ~ZEROPAD; --------------070302050101030406080200-- From owner-freebsd-standards@FreeBSD.ORG Thu Dec 25 00:49:52 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE263A64 for ; Thu, 25 Dec 2014 00:49:52 +0000 (UTC) Received: from nimbus.fccf.net (nimbus.fccf.net [77.77.144.35]) by mx1.freebsd.org (Postfix) with ESMTP id 79BB51D3E for ; Thu, 25 Dec 2014 00:49:49 +0000 (UTC) Received: from straylight.m.ringlet.net (unknown [91.211.191.230]) by nimbus.fccf.net (Postfix) with ESMTPSA id 434861B5 for ; Thu, 25 Dec 2014 02:40:03 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 25407f0 by straylight.m.ringlet.net (DragonFly Mail Agent v0.9); Thu, 25 Dec 2014 02:40:02 +0200 Date: Thu, 25 Dec 2014 02:40:02 +0200 From: Peter Pentchev To: Pedro Giffuni Subject: Re: Does posix say anything about the sign in NaNs ? Message-ID: <20141225004002.GA7015@straylight.m.ringlet.net> References: <549B1115.8000909@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <549B1115.8000909@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 00:49:52 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 24, 2014 at 02:16:37PM -0500, Pedro Giffuni wrote: > Hello; >=20 > I got the attached patch from OpenBSD. >=20 > It says: > ____ > Show the sign for NaN as per POSIX; from Elliott Hughes. > ok martynas@, millert@, doug@ > ____ >=20 > I can't find a reference in POSIX documentation to support it though. The message to OpenBSD's tech@ list that suggested this was http://marc.info/?l=3Dopenbsd-tech&m=3D141876375108892&w=3D2 The text from POSIX that it quotes may be found e.g. at http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html (search for "A double argument representing an infinity") > Anyone has a reason why we shouldn't adopt it, or a reference I can quote > on the commit log? Hope the above helps! > ps. Merry Christmas to everyone !! Same to you! :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUm1zdAAoJEGUe77AlJ98T0NEP/jYdtHE36q1XdNRIyGjU4w5g QlhHL2PXgakrPhwS218lS1jSlu9ozhk4LnOAzs/5KovEwdcE7sZ/XBfLmDp6gOUk mCKzVxvVGvg0E1WRx0yBPuLauahYrffiXw71MYj9AYq1AYrcBbqRsJyYe7p+XSFp MaEkq4L8tcE1jCJIgUDg2YYu30TM+Dzp7pzz5fX841UjMg6IDos29ZjqRyeL7rru li2erQLCTxFNV24ag3CmbJhMsGfSH7H90PfAeUoH948PhW2PBpfCYSTAKy1mgGz8 X2ZqPjCuk+6SmIvi/h/s81F88Fw4sXHQ0iQQuR7laEcGrC9jqy32X4TauhKEH+XJ bcU68zuWolAQts1uxyrBQSpW5vEUWRp9Acg39/npDtP0ACB0YZ1nu00r/lDm3eXS ouJ8cjuASNxGhfaRAdx8+JWsmUZyuD8+uMGuFoI6hyT0nzoUJPsLAvfKxZGmL3rC 7tVOTHJR+y8PrusgiodjUAPCeYLt4H5rQG8B/ELTSmM7G3ovJ8kuKHsLgPXbM7x9 ItS/sjYlJIAC9UukYQZpKf48mlQ1sqEn7OZ/MgSZxefqJlmk+CJzoLx/UDZE11n9 k76hZb7E7kivej5gtEA3Q6sUIGHJiIyLaCMW4X1mYjgggqcPc7BtH0wUQVsQ8Qrg 5qOO8v1VwTjJU/nCb8ab =m0PD -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From owner-freebsd-standards@FreeBSD.ORG Thu Dec 25 02:38:31 2014 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24E7B4C0 for ; Thu, 25 Dec 2014 02:38:31 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id C4C19182D for ; Thu, 25 Dec 2014 02:38:29 +0000 (UTC) Received: (qmail 16873 invoked by uid 99); 25 Dec 2014 02:38:23 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Dec 2014 02:38:23 +0000 Received: from [192.168.0.103] (unknown [190.157.136.22]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 8DAA71A0031; Thu, 25 Dec 2014 02:38:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Does posix say anything about the sign in NaNs ? From: Pedro Giffuni In-Reply-To: <20141225004002.GA7015@straylight.m.ringlet.net> Date: Wed, 24 Dec 2014 21:38:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <549B1115.8000909@FreeBSD.org> <20141225004002.GA7015@straylight.m.ringlet.net> To: Peter Pentchev X-Mailer: Apple Mail (2.1993) Cc: freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 02:38:31 -0000 > Il giorno 24/dic/2014, alle ore 19:40, Peter Pentchev = ha scritto: >=20 > On Wed, Dec 24, 2014 at 02:16:37PM -0500, Pedro Giffuni wrote: >> Hello; >>=20 >> I got the attached patch from OpenBSD. >>=20 >> It says: >> ____ >> Show the sign for NaN as per POSIX; from Elliott Hughes. >> ok martynas@, millert@, doug@ >> ____ >>=20 >> I can't find a reference in POSIX documentation to support it though. >=20 > The message to OpenBSD's tech@ list that suggested this was > http://marc.info/?l=3Dopenbsd-tech&m=3D141876375108892&w=3D2 >=20 OK, so the change seems to come from google. > The text from POSIX that it quotes may be found e.g. at > http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html > (search for "A double argument representing an infinity") >=20 >> Anyone has a reason why we shouldn't adopt it, or a reference I can = quote >> on the commit log? >=20 > Hope the above helps! >=20 Certainly, thanks! Pedro. From owner-freebsd-standards@FreeBSD.ORG Thu Dec 25 14:01:00 2014 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE76D912; Thu, 25 Dec 2014 14:01:00 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 81F0A64750; Thu, 25 Dec 2014 14:00:59 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 6785142677B; Fri, 26 Dec 2014 01:00:49 +1100 (AEDT) Date: Fri, 26 Dec 2014 01:00:48 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pedro Giffuni Subject: Re: Does posix say anything about the sign in NaNs ? In-Reply-To: <549B1115.8000909@FreeBSD.org> Message-ID: <20141225235228.H927@besplex.bde.org> References: <549B1115.8000909@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=R8o6R7hX c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=k5OLvdurW4alM8Hq76QA:9 a=jxxdyVgWQHFP4iSm:21 a=IaUWJBIx5GFWIWKm:21 a=CjuIK1q_8ugA:10 Cc: freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 14:01:00 -0000 On Wed, 24 Dec 2014, Pedro Giffuni wrote: > I got the attached patch from OpenBSD. > > It says: > ____ > Show the sign for NaN as per POSIX; from Elliott Hughes. > ok martynas@, millert@, doug@ > ____ > > I can't find a reference in POSIX documentation to support it though. The behaviour is implementation-defined. From n869.txt for printf: X A double argument representing an infinity is X converted in one of the styles [-]inf or [-]infinity X -- which style is implementation-defined. A X double argument representing a NaN is converted in X one of the styles [-]nan or [-]nan(n-char-sequence) X -- which style, and the meaning of any n-char- X sequence, is implementation-defined. The F X conversion specifier produces INF, INFINITY, or NAN X instead of inf, infinity, or nan, respectively.220) "style" is not clearly defined. The format for input in strtod() is formally defined as [-]something without using the term "style", but the specication for actually handling the minus sign is even less complete (see below). The library intentionally suppresses the sign for NaNs on output. This is consistent with it ignororing the sign for NaNs on input. > Anyone has a reason why we shouldn't adopt it, or a reference I can quote > on the commit log? It is not needed, and is inconsistent with the treatment for input. It is not very useful. Consistent, documented support for the [-]nan(n-char-sequence) support would be useful. This support should be like what gdb does, but better. Leave it for the gdtoa vendor to change. For input, then . The details are unspecified (not even implementation-defined) and very machine-dependent in practice even for the negating normal numbers. From n869.txt for strtod: X string. If the subject sequence begins with a minus sign, | X the sequence is interpreted as negated.235) A character footnote 235: X It is unspecified whether a minus-signed sequence is X converted to a negative number directly or by negating X the value resulting from converting the corresponding X unsigned sequence (see F.5); the two methods may yield X different results if rounding is toward positive or X negative infinity. In either case, the functions honor X the sign of zero if floating-point arithmetic supports X signed zeros. This is under-specified. "interpreted as negated" is not defined anywere, so it must have its English meaning, and that meaning is unclear in all cases where rounding or NaNs are involved, and also for the arcane -0. The footnote doesn't specify anything, since footnotes are not part of the standard. It just gives the hint that any reasonable method may be used, although the methods give different results. It gives the hint that -0 should work. It doesn't say anything for NaNs. The two methods may give different results for NaNs too. Direct interpretation sets the minus bit, as if by copysign() from -1. Whether negating a NaN toggles its sign bit is very implementation-dependent. (The behaviour differs even on i386. Negation is normally implemented using fchs in i387. SSE doesn't have fchs, so negation must be implemented as subtraction from 0, and IIRC this doesn't change the sign bit for NaNs. This gives the follow behaviours on i386 for -x on the NaN _variable_ x: - gcc for all precisions: all cases use fchs, so flip the sign - clang -msse*: clang is incompatible. It uses SSE* for float and double precision, but fchs for long double precision. Thus -x flips the sign bit for long double precision only. And on amd64: - both gcc and clang use SSE for float and double precision, so the behaviour is the same as for clang -msse* on i386. Toggling the sign bit for +-0 has the same machine-dependenices as for NaNs if done naively. The library cares about this case. I think it uses a direct method (more hackish than copysign) since anything involving an expression would be even more unportable than hacking on the sign bit.) I'm not sure how the library handles "-nan" on input, but since it produces a NaN with a sign bit of 0 on i386, it apparently forces the sign bit to 0, unlike what it does for "-0" and "-0.1") (replace 0.1 by a number that should be affected by the rounding mode if necessary to get an interesting example). In my version of libm, most of the 2-arg functions have hackish changes related to the above machine dependencies to force consistent results for pairs of NaNs. To stop the result of x+y (where x and y are NaNs) depending on the quiet bit and the precision (due to it being evaluated in different register sets for different precisions) and sometimes also on the compiler ordering of x+y, expressions are forced to long double precision early. Hardware generally chooses one of x or y (quieted) for the result of x+y. If the result depends on the ordering and the ordering is unpredictable, then sign bits in NaNs get lost just like value bits in NaNs. Bruce From owner-freebsd-standards@FreeBSD.ORG Thu Dec 25 14:54:44 2014 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA6FD135 for ; Thu, 25 Dec 2014 14:54:44 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id 667661D25 for ; Thu, 25 Dec 2014 14:54:43 +0000 (UTC) Received: (qmail 57383 invoked by uid 99); 25 Dec 2014 14:54:42 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Dec 2014 14:54:42 +0000 Received: from [192.168.0.103] (unknown [190.157.136.22]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id E76791A0155; Thu, 25 Dec 2014 14:53:57 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Does posix say anything about the sign in NaNs ? From: Pedro Giffuni In-Reply-To: <20141225235228.H927@besplex.bde.org> Date: Thu, 25 Dec 2014 09:53:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <003E7D36-61E0-4572-A98C-24351F6ADF5A@freebsd.org> References: <549B1115.8000909@FreeBSD.org> <20141225235228.H927@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1993) Cc: freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 14:54:44 -0000 Hello; > Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans = ha scritto: >=20 > On Wed, 24 Dec 2014, Pedro Giffuni wrote: >=20 >> I got the attached patch from OpenBSD. >>=20 >> It says: >> ____ >> Show the sign for NaN as per POSIX; from Elliott Hughes. >> ok martynas@, millert@, doug@ >> ____ >>=20 >> I can't find a reference in POSIX documentation to support it though. >=20 > The behaviour is implementation-defined. =46rom n869.txt for printf: >=20 > X A double argument representing an infinity is > X converted in one of the styles [-]inf or [-]infinity > X -- which style is implementation-defined. A > X double argument representing a NaN is converted in > X one of the styles [-]nan or [-]nan(n-char-sequence) > X -- which style, and the meaning of any n-char- > X sequence, is implementation-defined. The F > X conversion specifier produces INF, INFINITY, or NAN > X instead of inf, infinity, or nan, respectively.220) >=20 > "style" is not clearly defined. The format for input in strtod() > is formally defined as [-]something without using the term "style", > but the specication for actually handling the minus sign is even less > complete (see below). >=20 > The library intentionally suppresses the sign for NaNs on output. > This is consistent with it ignororing the sign for NaNs on input. >=20 Interesting and pretty much the reason why I wanted to discuss the = change. I can see the sign information is important for infinity but indeed it = makes very little sense (if any) for NaN. OTOH, we are doing an extra = assignment to hide something the standard permits. If we are ignoring the sign of = NaNs on input there should be no such sign information in the first place and ignoring the value is unnecessary. While I am tempted to follow the change, I think it is pretty much = innocuous as no reasonably correct program should depend on the sign of NaN. Pedro. From owner-freebsd-standards@FreeBSD.ORG Thu Dec 25 19:35:37 2014 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F456414 for ; Thu, 25 Dec 2014 19:35:37 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 555A76480D for ; Thu, 25 Dec 2014 19:35:36 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rl12so7144091iec.40 for ; Thu, 25 Dec 2014 11:35:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=rpYr4n8jLeb5bumYzyY9AEv18S9rXEGkX0qGDhMlhmI=; b=bntshxBoi1hdO1lRp6OOY3CdB5NGR670AwubnBNKiu1gA3/LwPyofGTthVE6Rqw3Ex zQVbHRf0J9eIMp0mL4TRhhcXh4sqQXtgvx9QnnQH8znITMfe+kdXqxDmgBhdQ5sDqbmN vJbbgZMNdfKNeC0lkRd2QOgwhuRNaCWI8iTdSJk8HwaBVCl70Lb3Cjsdfq1+/cIozuf6 GFrGDRl07roi8DUEghQaNnAdJS0HKTZhengroaMu1ZGle5xWSuLZunfc1RJ9gU3heLdu CtL6X2BhsF2m3ukx+z8ffQwcuaNKTT+185+QbWZVc7zg8BhHbjz3PtajekzMZHCQobT8 QKBA== X-Gm-Message-State: ALoCoQkvtKkjJNZBCym6LdM9xcITVwAM0u82VLp2w72HICeIICn1rJFavUeI69NeSEXVTU3sRpD+ X-Received: by 10.50.28.20 with SMTP id x20mr31835508igg.27.1419536130571; Thu, 25 Dec 2014 11:35:30 -0800 (PST) Received: from netflix-mac-wired.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id qr1sm9626600igb.18.2014.12.25.11.35.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Dec 2014 11:35:29 -0800 (PST) Sender: Warner Losh Subject: Re: Does posix say anything about the sign in NaNs ? Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BC4BA5D4-07DC-4C31-88B1-B87C64A07005"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <003E7D36-61E0-4572-A98C-24351F6ADF5A@freebsd.org> Date: Thu, 25 Dec 2014 12:35:27 -0700 Message-Id: <2A81225A-09C3-4DFF-A4DA-6B440AFFB857@bsdimp.com> References: <549B1115.8000909@FreeBSD.org> <20141225235228.H927@besplex.bde.org> <003E7D36-61E0-4572-A98C-24351F6ADF5A@freebsd.org> To: Pedro Giffuni X-Mailer: Apple Mail (2.1993) Cc: freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 19:35:37 -0000 --Apple-Mail=_BC4BA5D4-07DC-4C31-88B1-B87C64A07005 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 25, 2014, at 7:53 AM, Pedro Giffuni wrote: >=20 > Hello; >=20 >> Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans = ha scritto: >>=20 >> On Wed, 24 Dec 2014, Pedro Giffuni wrote: >>=20 >>> I got the attached patch from OpenBSD. >>>=20 >>> It says: >>> ____ >>> Show the sign for NaN as per POSIX; from Elliott Hughes. >>> ok martynas@, millert@, doug@ >>> ____ >>>=20 >>> I can't find a reference in POSIX documentation to support it = though. >>=20 >> The behaviour is implementation-defined. =46rom n869.txt for printf: >>=20 >> X A double argument representing an infinity is >> X converted in one of the styles [-]inf or [-]infinity >> X -- which style is implementation-defined. A >> X double argument representing a NaN is converted in >> X one of the styles [-]nan or [-]nan(n-char-sequence) >> X -- which style, and the meaning of any n-char- >> X sequence, is implementation-defined. The F >> X conversion specifier produces INF, INFINITY, or NAN >> X instead of inf, infinity, or nan, respectively.220) >>=20 >> "style" is not clearly defined. The format for input in strtod() >> is formally defined as [-]something without using the term "style", >> but the specication for actually handling the minus sign is even less >> complete (see below). >>=20 >> The library intentionally suppresses the sign for NaNs on output. >> This is consistent with it ignororing the sign for NaNs on input. >>=20 >=20 >=20 > Interesting and pretty much the reason why I wanted to discuss the = change. >=20 > I can see the sign information is important for infinity but indeed it = makes > very little sense (if any) for NaN. OTOH, we are doing an extra = assignment > to hide something the standard permits. If we are ignoring the sign of = NaNs > on input there should be no such sign information in the first place = and > ignoring the value is unnecessary. >=20 > While I am tempted to follow the change, I think it is pretty much = innocuous > as no reasonably correct program should depend on the sign of NaN. My only concern with this change is that numeric programs might actually = break because they know this implementation detail. Its here some way to = discover if things my pysci or R have any change in behavior here? In = addition to the standard, numerical methods have much apocrypha = associated with them. Warner --Apple-Mail=_BC4BA5D4-07DC-4C31-88B1-B87C64A07005 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUnGcAAAoJEGwc0Sh9sBEAqFIP/R5A7n+RmWNgOOb5SLpdOvN6 zUBZaIQeDCakL6cblVH9Uea9MmyjnRjka1Z/IZAnuhJFZwTK3cJOauUI103DdT57 qDCqwZi27FVlQbcjk5hzBAyE8lvdw79xd2VyyUv6wP9PyU9ZMuY89OHCWy9WeKvT R98jDJ1zvZzREIEI2nVhYmlrNZAuehLpU+h44mP1Ob5vWZOt5ASojFyfSPZWgDqJ SVgkiAxKWoGTQhjqr57RTGsmGpKXp8YV5B2AhI0sI+DWhHBblp7+N/6XmWBZZa4D fjTmeixsfagdFa2n8PhBhMBW4EtG5UtfU/oU1M0Mmvz816WDibfblFRBYPAUAScV RNkPU1lT4Z4RLUf+7E3KOxXZWYQWLtxnAU5sjSGxW7FQ9xlxvU7+wKjCIIslvieM gyLpz4mKlflWqpmbu5f4mV7EXXPr7R7USGtoxoa+f9YjI04rWreQ4PNwl763IFeL U3ghktFjJUG8luMEEemYM2uaTOUxS0MfWlbrkO3VoFUdFsgO04DkI+Oxl1gnlDP0 A2a9HnTb2npCZc9ndlHa7nb96jjUVlVz90GeXFmgSNPE8F0q3KPnYnOzxRwE9aKF f0e38gep0BlDv4l/byxhYNDXCIo3vGcAhgH2W1uOxjmDI8TQ2J8FYc07KfMIBQTl 81ZHzSVhu48ifuoOa0Fp =C5kF -----END PGP SIGNATURE----- --Apple-Mail=_BC4BA5D4-07DC-4C31-88B1-B87C64A07005-- From owner-freebsd-standards@FreeBSD.ORG Thu Dec 25 20:35:09 2014 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDA6532F for ; Thu, 25 Dec 2014 20:35:09 +0000 (UTC) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 715242DB5 for ; Thu, 25 Dec 2014 20:35:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1419539702; bh=d5IAv6vlQux4qC3rmaQA0p1PJt11Jl5mFAWpnxuCq7I=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=PqnjAMuLAPawLYyCDKw6eW08vRxEGqlHtynvHaYY+Xqio/T3sD0M6xEu1L4EpGIRxHg8v77gsef11yg8J47QuILTBZCO1uc+ElJhyA7/AdBZvyYkhypA4DOcAWXjjtGFxeyzzTtWHcGaBaYoQBN/V/qd2TxkNPaxS3F5CGIgPQXkuLCW6CM0R3V0848hOw6TlZhb9vhbI3jLyLGF+ze2mTYkL3WMxPo7SPla4BO1YWsb0AhDqNp6TUNWNXGgH2ttKy6j/sYLTanJEc4WGqC/FyF7SxP4NpMY5MDyIxJ9BuGgc78+yOQqyo1chGFwNmSUaMypqBk1QW2zj2U8tjjMGw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=uYjmxxhK78xiHFKUqj5XviPTpNceH9FhhL+nWHcNw/7X7A90OOGfFisp+F0V2JLMGYvWLgJ0x3vUfS/DEwefTbqmZsW0Bvxl66B/51heVta7U8Ui7a+akUbcycZcMZHzr128dcN2YIeCJcAwFP5X7BTH4W8cdnTiv9OHMediyNcR+9xIvkYgbGnB3xo4UMaJKYtGX7SXo2oNqWSc3XcE0DqGUI1GLvUywI29iYheiEdHopQ++s2RyBGbqdbYRvDsOBFa/YC8V8dKbwvSh3wYTBu4LWPwOGwrXyaS/yAXfk3qrEnAZ8R3GKD/oCGLnMwhSUvrXqxDK7EUOkNROUJ0Ww==; Received: from [98.139.215.140] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 25 Dec 2014 20:35:02 -0000 Received: from [98.139.211.202] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 25 Dec 2014 20:35:02 -0000 Received: from [127.0.0.1] by smtp211.mail.bf1.yahoo.com with NNFMP; 25 Dec 2014 20:35:02 -0000 X-Yahoo-Newman-Id: 355196.36589.bm@smtp211.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zOawjpwVM1lCfRGJcFOIjwdnZE.TFfH3PLt2z.1yMI0.D9Z rezJb8gCJuplgTwkn87vPnxoGZ2aZwKxQO.oaH5eG53S05P.E3UmRQcsa0oT wNSRwkW7JYTb.3C2DHDAQEgPeDh2Tze0T_SItSRUU8iA9gUSeRdgFANbgCnj .xHLfsSPpKdMiXRTiFa_6vSkqP.m.I523gYd5LfAV10s.WqyzHFzKkdBeUb_ Ahi17nrsvd7Ji4VLB7agGhNbdhvEKNmRR.lX.u37gsFBPhMkEUxxegEeeIN0 W7VNw_trUhJp_FzsKGeuYa7uh.X_wtMHaPQzGzOGOlPTP6qy4QuhAQ1jipug tzgKmahSPBjV2LeZcLr4BorLsh5i1NkkRGN0uGwPA4mXrg4RHS.K3iDDrUc3 gHLcyeAvK9dRogcb5ay9Usd4CwofUEPbQkQDsYNYX1LkuY_s_eZ1j2RVPY1j CVd9aqLBA4zgg0T0OWVfy8yoLOEMlFbrJPL66tM_BBuf8xyicp2OAXl0g2P7 dyS7jIRfoUPahWx.hqWQOEgUHbPm5ofYzCZGIQSDbWD._90pDMja.c64aSOn sisfG4ifI4Jw0sCuBexFuaw6Oke6GxEKbzwfM1yVqLDw1HaJlu9DNWdBoKkV QlPi0llhw3IJmbGngMVLcj4pfIz8OPZ.HvM9sOHHlXakkYZg2t5t9zrUfg8x xpcL89jyk X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <549C7516.5070204@FreeBSD.org> Date: Thu, 25 Dec 2014 15:35:34 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: Does posix say anything about the sign in NaNs ? References: <549B1115.8000909@FreeBSD.org> <20141225235228.H927@besplex.bde.org> <003E7D36-61E0-4572-A98C-24351F6ADF5A@freebsd.org> <2A81225A-09C3-4DFF-A4DA-6B440AFFB857@bsdimp.com> In-Reply-To: <2A81225A-09C3-4DFF-A4DA-6B440AFFB857@bsdimp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Dec 2014 20:35:09 -0000 On 12/25/14 14:35, Warner Losh wrote: >> On Dec 25, 2014, at 7:53 AM, Pedro Giffuni wrote: >> >> Hello; >> >>> Il giorno 25/dic/2014, alle ore 09:00, Bruce Evans ha scritto: >>> >>> On Wed, 24 Dec 2014, Pedro Giffuni wrote: >>> >>>> I got the attached patch from OpenBSD. >>>> >>>> It says: >>>> ____ >>>> Show the sign for NaN as per POSIX; from Elliott Hughes. >>>> ok martynas@, millert@, doug@ >>>> ____ >>>> >>>> I can't find a reference in POSIX documentation to support it though. >>> The behaviour is implementation-defined. From n869.txt for printf: >>> >>> X A double argument representing an infinity is >>> X converted in one of the styles [-]inf or [-]infinity >>> X -- which style is implementation-defined. A >>> X double argument representing a NaN is converted in >>> X one of the styles [-]nan or [-]nan(n-char-sequence) >>> X -- which style, and the meaning of any n-char- >>> X sequence, is implementation-defined. The F >>> X conversion specifier produces INF, INFINITY, or NAN >>> X instead of inf, infinity, or nan, respectively.220) >>> >>> "style" is not clearly defined. The format for input in strtod() >>> is formally defined as [-]something without using the term "style", >>> but the specication for actually handling the minus sign is even less >>> complete (see below). >>> >>> The library intentionally suppresses the sign for NaNs on output. >>> This is consistent with it ignororing the sign for NaNs on input. >>> >> >> Interesting and pretty much the reason why I wanted to discuss the change. >> >> I can see the sign information is important for infinity but indeed it makes >> very little sense (if any) for NaN. OTOH, we are doing an extra assignment >> to hide something the standard permits. If we are ignoring the sign of NaNs >> on input there should be no such sign information in the first place and >> ignoring the value is unnecessary. >> >> While I am tempted to follow the change, I think it is pretty much innocuous >> as no reasonably correct program should depend on the sign of NaN. > My only concern with this change is that numeric programs might actually break because they know this implementation detail. Its here some way to discover if things my pysci or R have any change in behavior here? In addition to the standard, numerical methods have much apocrypha associated with them. > > Warner Well, you should only get a NaN when you did something wrong in your calculation and that's pretty much the end of it. Googling around, it appears glibc did a similar change, and it did cause issues to someone: http://stackoverflow.com/questions/3772835/getting-a-negative-nan-on-g-4-4-3-is-this-standard Given it's implementation dependent I now think it is better to keep the historical behavior consistent so I won't be committing the change. Cheers, Pedro. From owner-freebsd-standards@FreeBSD.ORG Sat Dec 27 23:00:32 2014 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EC7DBA7; Sat, 27 Dec 2014 23:00:32 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khavrinen.csail.mit.edu", Issuer "Client CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 460C884C; Sat, 27 Dec 2014 23:00:32 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.9/8.14.9) with ESMTP id sBRN0UW9050763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Sat, 27 Dec 2014 18:00:30 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.9/8.14.9/Submit) id sBRN0TOB050760; Sat, 27 Dec 2014 18:00:29 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21663.14861.388944.805245@khavrinen.csail.mit.edu> Date: Sat, 27 Dec 2014 18:00:29 -0500 From: Garrett Wollman To: Bruce Evans Subject: Re: Does posix say anything about the sign in NaNs ? In-Reply-To: <20141225235228.H927@besplex.bde.org> References: <549B1115.8000909@FreeBSD.org> <20141225235228.H927@besplex.bde.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Sat, 27 Dec 2014 18:00:30 -0500 (EST) Cc: Pedro Giffuni , freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2014 23:00:32 -0000 < said: > On Wed, 24 Dec 2014, Pedro Giffuni wrote: >> I got the attached patch from OpenBSD. >> >> It says: >> ____ >> Show the sign for NaN as per POSIX; from Elliott Hughes. >> ok martynas@, millert@, doug@ >> ____ >> >> I can't find a reference in POSIX documentation to support it though. > The behaviour is implementation-defined. From n869.txt for printf: An old draft of the C standard is not necessarily relevant here, since POSIX may place requirements on implementations beyond those of C. The 2008 POSIX standard (aka SUSv7) had this to say (XBD7 p. 247, ): An implementation may give zero and non-numeric values, such as infinities and NaNs, a sign, or may leave them unsigned. Wherever such values are unsigned, any requirement in POSIX.1-2008 to retrieve the sign shall produce an unspecified sign and any requirement to set the sign shall be ignored. I haven't checked the current edition to see whether it differs in this regard, but I doubt it. XSH7 page 932 (fscanf()) additionally requires: If the fprintf ( ) family of functions generates character string representations for infinity and NaN (a symbolic entity encoded in floating-point format) to support IEEE Std 754-1985, the fscanf ( ) family of functions shall recognize them as input. My view would be that FreeBSD is free to determine that NaN is an unsigned value, and no conforming application can distinguish signed NaNs (either positive or negative) from unsigned NaNs. -GAWollman