Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 58358 invoked from network); 23 Apr 2008 23:13:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Apr 2008 23:13:56 -0000 Received: (qmail 81773 invoked by uid 500); 23 Apr 2008 23:13:58 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 81754 invoked by uid 500); 23 Apr 2008 23:13:57 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 81743 invoked by uid 99); 23 Apr 2008 23:13:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Apr 2008 16:13:57 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Apr 2008 23:13:14 +0000 Received: from exchmail01.Blue.Roguewave.Com (exchmail01.blue.roguewave.com [10.22.129.22]) by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m3NNDPsW014634 for ; Wed, 23 Apr 2008 23:13:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: svn commit: r650902 - /stdcxx/trunk/src/num_put.cpp Date: Wed, 23 Apr 2008 17:13:06 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: svn commit: r650902 - /stdcxx/trunk/src/num_put.cpp Thread-Index: AcilVbzSM7HnfHVZRZuSGzDO24P4bAAOIoTAAAC3/YA= References: <20080423152034.1B7D71A9832@eris.apache.org> From: "Travis Vitek" To: X-Virus-Checked: Checked by ClamAV on apache.org =20 > Eric Lemings wrote: >=20 > >> -----Original Message----- >> From: faridz@apache.org [mailto:faridz@apache.org]=20 >>=20 >> Author: faridz >> Date: Wed Apr 23 08:20:07 2008 >> New Revision: 650902 >>=20 >> URL: http://svn.apache.org/viewvc?rev=3D650902&view=3Drev >> Log: >> 2008-04-23 Farid Zaripov >>=20 >> STDCXX-880=09 >> * src/num_put.cpp: Added simple overloads of the=20 >> __rw_isfinite(), __rw_signbit(), __rw_isinf(), >> __rw_isnan(), __rw_isqnan(), __rw_issnan() >> for float and long double types. >>=20 >> Modified: >> stdcxx/trunk/src/num_put.cpp >>=20 >=20 > >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. 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? 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? >Brad. >