incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: svn commit: r650902 - /stdcxx/trunk/src/num_put.cpp
Date Thu, 24 Apr 2008 06:01:21 GMT
Farid Zaripov wrote:
>> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com]
>> To: dev@stdcxx.apache.org
>> 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.
> 
>   Right.
> 
>> 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().

Right, but they don't seem to do anything useful on any platform.
AFAICT, __rw_fmat_infinite() only ever actually gets called to
format double Infinities and NaNs. floats are unconditionally
formatted using sprintf() and so are long doubles unless they
are the same size as double. Is that correct? And if so, why
don't we format float infinities using __rw_fmat_infinite()?
Or why don't we have a float and long double overload for it?

> 
>> 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().

This makes sense to me.

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

It's in libsunmath that we don't link with and don't want to start
just to look at a few bits. Here's the background on the change(s):
http://www.nabble.com/Re%3A-svn-commit%3A-r646396----stdcxx-trunk-src-num_put.cpp-td16599410.html#a16599410

Martin


Mime
View raw message