stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farid Zaripov" <>
Subject Re: svn commit: r650902 - /stdcxx/trunk/src/num_put.cpp
Date Thu, 24 Apr 2008 05:45:25 GMT
> From: Travis Vitek []
> To:
> Suject: RE: svn commit: r650902 - /stdcxx/trunk/src/num_put.cpp

>>With just a quick review, this change looks a bit suspicious.  The
>>respective overloads for type double are all defined within
>>conditional-compile directives.  It follows that float and long double
>>overloads would be defined similarly unless I'm missing something.
>The overloads on double are in platform specific #ifdef blocks because
>they have platform specific code in them (_finite, finite, isfinite). At
>least that is the only reason I see for it. So I don't really see the
>overloads on float and double outside of platform specific blocks as a
>problem as there is no platform specific code in them.


>I'm more worried about why the overloads on float and long double are
>added at all. If they are only being called from __rw_fmat_infinite(),
>and that function only works with a double, then I see no motivation for
>the overloads.

  The float, double and long double versions of __rw_isfinite() are called
from __rw_put_num() prior to call __rw_fmat_infinite().

>I'm also wondering why we provide default implementations of these
>functions if we know good and well that the results are wrong (for
>platforms that don't define _WIN32, _RWSTD_OS_SUNOS, or fpclassify).
>Shouldn't we fail to compile in this case?

  We need just convert NaN or Inf value to string. If we don't know the platform-specific
functions or some platform doesn't provides such functions, we should fallback to
using printf().

>The other thing that freaks me out is the implementation of __rw_signbit
>on platforms defining _RWSTD_OS_SUNOS. It assumes something similar to
>IEEE-745 double representation. This may be a safe assumption for the
>time being, but what happens if the user compiles with -fnonstd? Does
>this still work?

  Martin has changed the __rw_signbit() to not use signbit() on Solaris to avoid
linking with libsunmath (and libm?) libraries. I see in documentation that copysign()
is also present on Solaris. Can you check in what library located copysign()?


  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message