incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject RE: svn commit: r650902 - /stdcxx/trunk/src/num_put.cpp
Date Thu, 24 Apr 2008 00:08:17 GMT
 

>Travis Vitek wrote:
>
>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.
>
>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?

As opposed to serializing bad results...

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

With all that said, the sum of the changes to num_put.cpp seem to
eliminate the unexpected failures in the 22.locale.num.put test on
both sunos-5.10-gcc-4.1.1 and aix-5.3-vacpp-8.0 12D builds.

Travis

Mime
View raw message