svn commit: r253764 - head/lib/msun/src

Bruce Evans brde at optusnet.com.au
Mon Jul 29 11:00:12 UTC 2013


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


More information about the svn-src-all mailing list