>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
