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 <b...@optusnet.com.au> wrote: > On Mon, 29 Jul 2013, David Chisnall wrote: > >> Author: theraven >> Date: Mon Jul 29 08:32:13 2013 >> New Revision: 253764 >> URL: http://svnweb.freebsd.org/changeset/base/253764 >> >> Log: >> Reenable the isnan(double) / isinf(double) declarations when targeting C89 + >> SUSv2 mode. > > This isn't reenabling. but breaks the isnan() and isinf() macros by > #undefing them. > >> Modified: >> head/lib/msun/src/math.h >> >> Modified: head/lib/msun/src/math.h >> ============================================================================== >> --- 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 != __x); >> } >> >> +/* >> + * 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 >> + > > 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 >= 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: > > @ #if __BSD_VISIBLE || __XSI_VISIBLE > > Boolean conditions. You obfuscate the boolean condition __XSI_VISIBLE > by writing it as __XSI_VISIBLE > 0. > > @ double j0(double); > @ double j1(double); > @ double jn(int, double); > @ double y0(double); > @ double y1(double); > @ double yn(int, double); > @ @ #if __XSI_VISIBLE <= 500 || __BSD_VISIBLE > > 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 <= 500 by itself would be > broken since it would be satisfied by __XSI_VISIBLE == 0 which means > non-XSI. > > @ double gamma(double); > @ #endif > @ @ #if __XSI_VISIBLE <= 600 || __BSD_VISIBLE > > As above, for a later XSI. > > You obfuscate the version tests further using '<' instead of '<='. '< 600' > does make more sense than '<= 500', since if 5 and 6 represent major > releases then API changes should occur at 600 not at 501. > > @ double scalb(double, double); > @ #endif > @ #endif /* __BSD_VISIBLE || __XSI_VISIBLE */ > >> double acos(double); >> double asin(double); >> double atan(double); >> > > Bruce
signature.asc
Description: Message signed with OpenPGP using GPGMail
