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

[David Chisnall]

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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20130729/f0abd467/attachment.sig>