Date: Mon, 29 Jul 2013 13:00:31 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r253764 - head/lib/msun/src Message-ID: <4F2196BB-1873-458B-8C4F-9D7A351A4426@FreeBSD.org> In-Reply-To: <20130729201847.K1146@besplex.bde.org> References: <201307290832.r6T8WEYB007487@svn.freebsd.org> <20130729201847.K1146@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_A9DD75D9-C81A-40E6-B5DB-5715E779E80E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Bruce, It's very difficult within this verbiage to work out what you believe = the correct code should look like. Please either provide a patch or = commit the fix yourself. David On 29 Jul 2013, at 11:59, Bruce Evans <brde@optusnet.com.au> wrote: > On Mon, 29 Jul 2013, David Chisnall wrote: >=20 >> Author: theraven >> Date: Mon Jul 29 08:32:13 2013 >> New Revision: 253764 >> URL: http://svnweb.freebsd.org/changeset/base/253764 >>=20 >> Log: >> Reenable the isnan(double) / isinf(double) declarations when = targeting C89 + SUSv2 mode. >=20 > This isn't reenabling. but breaks the isnan() and isinf() macros by > #undefing them. >=20 >> Modified: >> head/lib/msun/src/math.h >>=20 >> Modified: head/lib/msun/src/math.h >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/lib/msun/src/math.h Mon Jul 29 08:08:43 2013 = (r253763) >> +++ head/lib/msun/src/math.h Mon Jul 29 08:32:13 2013 = (r253764) >> @@ -209,6 +209,21 @@ __inline_isnanl(__const long double __x) >> return (__x !=3D __x); >> } >>=20 >> +/* >> + * Version 2 of the Single UNIX Specification (UNIX98) defined = isnan() and >> + * isinf() as functions taking double. C99, and the subsequent = POSIX revisions >> + * (SUSv3, POSIX.1-2001, define it as a macro that accepts any real = floating >> + * point type. If we are targeting SUSv2 and C99 or C11 (or C++11) = then we >> + * expose the newer definition, assuming that the language spec = takes >> + * precedence over the operating system interface spec. >> + */ >> +#if __XSI_VISIBLE > 0 && __XSI_VISIBLE < 600 && __ISO_C_VISIBLE < = 1999 >> +#undef isinf >> +#undef isnan >> +int isinf(double); >> +int isnan(double); >> +#endif >> + >=20 > Old versions declared these functions by temporarily hiding the macro > definitions using parentheses, and also sorted the declarations = differently > (into the __BSD_VISIBLE || __ISO_C_VISIBLE >=3D 1999 || __XSI_VISIBLE > section. The __ISO_C_VISIBLE part of that ifdef is not quite broken = for > these functions, since although they aren't in C99, I think only > non-conforming code can use them as functions). If the above ifdef is > correct, then it is still unsorted. Other ifdefs for fine-grained > XSI ifdefs are sorted later, in ascending order on __XSI_VISIBLE. > The others are written with slightly unclear nested conditions for > __XSI_VISIBLE: >=20 > @ #if __BSD_VISIBLE || __XSI_VISIBLE >=20 > Boolean conditions. You obfuscate the boolean condition __XSI_VISIBLE > by writing it as __XSI_VISIBLE > 0. >=20 > @ double j0(double); > @ double j1(double); > @ double jn(int, double); > @ double y0(double); > @ double y1(double); > @ double yn(int, double); > @ @ #if __XSI_VISIBLE <=3D 500 || __BSD_VISIBLE >=20 > Now the same boolean condition for the __BSD_VISIBLE part (obfuscated = by > writing the conditions in the opposite order), but a further = restriction > for the __XSI_VISIBLE part. __XSI_VISIBLE <=3D 500 by itself would be > broken since it would be satisfied by __XSI_VISIBLE =3D=3D 0 which = means > non-XSI. >=20 > @ double gamma(double); > @ #endif > @ @ #if __XSI_VISIBLE <=3D 600 || __BSD_VISIBLE >=20 > As above, for a later XSI. >=20 > You obfuscate the version tests further using '<' instead of '<=3D'. = '< 600' > does make more sense than '<=3D 500', since if 5 and 6 represent major > releases then API changes should occur at 600 not at 501. >=20 > @ double scalb(double, double); > @ #endif > @ #endif /* __BSD_VISIBLE || __XSI_VISIBLE */ >=20 >> double acos(double); >> double asin(double); >> double atan(double); >>=20 >=20 > Bruce --Apple-Mail=_A9DD75D9-C81A-40E6-B5DB-5715E779E80E 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJR9llgAAoJEKx65DEEsqId7jkQAKSBPCUQFKIlzXUIrQek4gQ4 hTbMjSvmQ5mP0bCJjx5vHekhf830cjcwCuithA2SVAhnzkw+rIyTW0w96COcYw+K 0nvluGSxA9/veuOp+IqZfMFpau6pIsdtzuJdVYHrJMkG+03DyjqChhky8pdo/wmA QaevlALltc9N+fM2CvA5ANMCkfEo2j7gTN3xA5rqVNks2mzc2b4KMn6k/t99m3PY VcYojPWFmOvl1inXjZORD0maN1nmCsrcG2GWPPjjjExRsxSenZKW8P1w2415osW4 Ex/mcb459EfocAVlkfn3EA/0aeZvPIdNbLUZEsdcrQsVM5yBE4vzR1dXk49nwo3P rwDDH9GKi34f4UdrVcuYJzyYR9EpJvyLoluqghGY6SrlerBiTR061dVIrG+jXP5a dj27VHUc923+FIu26URnCAQR+eBaho6kNPT7WVvJb4il41lVfImx6Aj4TayGM0v1 PKWkjvJB38wn7UCfWJgmfIJQ2U/2saIADZVrmk65nQpxr64JZdz8hykEUawNxOof +0kN6DBVySGsIYV39HfsEjKnMPRdDPUI778kdK869cdYQcC8O0+3FdHaG7x2gDAq j65s9n+D1uY9AemwCOidOKFwdQflfify8erJILtlOFVxclCIGFq4hPQ4zPeqF7je XcLsmUJ1dwwcAj0Pqn5R =i2RF -----END PGP SIGNATURE----- --Apple-Mail=_A9DD75D9-C81A-40E6-B5DB-5715E779E80E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F2196BB-1873-458B-8C4F-9D7A351A4426>