Return-Path: 
 <issues-return-833-apmail-stdcxx-issues-archive=stdcxx.apache.org@stdcxx.apache.org>
Delivered-To: apmail-stdcxx-issues-archive@locus.apache.org
Received: (qmail 46682 invoked from network); 25 Mar 2008 17:27:30 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 25 Mar 2008 17:27:30 -0000
Received: (qmail 91391 invoked by uid 500); 25 Mar 2008 17:27:29 -0000
Delivered-To: apmail-stdcxx-issues-archive@stdcxx.apache.org
Received: (qmail 91369 invoked by uid 500); 25 Mar 2008 17:27:29 -0000
Mailing-List: contact issues-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@stdcxx.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@stdcxx.apache.org>
List-Post: <mailto:issues@stdcxx.apache.org>
List-Id: <issues.stdcxx.apache.org>
Reply-To: dev@stdcxx.apache.org
Delivered-To: mailing list issues@stdcxx.apache.org
Received: (qmail 91360 invoked by uid 99); 25 Mar 2008 17:27:29 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Mar 2008 10:27:29 -0700
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Mar 2008 17:26:58 +0000
Received: from brutus (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id 4A759234C0AD
	for <issues@stdcxx.apache.org>; Tue, 25 Mar 2008 10:25:24 -0700 (PDT)
Message-ID: <2001248776.1206465924303.JavaMail.jira@brutus>
Date: Tue, 25 Mar 2008 10:25:24 -0700 (PDT)
From: "Martin Sebor (JIRA)" <jira@apache.org>
To: issues@stdcxx.apache.org
Subject: [jira] Commented: (STDCXX-463) [HP-UX 11.23] printf("%Lg", -NAN)
 formatted incorrectly
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org


    [ https://issues.apache.org/jira/browse/STDCXX-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582020#action_12582020 ] 

Martin Sebor commented on STDCXX-463:
-------------------------------------

Here's a test case that confirms what Dennis says (not that both the positive and the negative NaN generated by the compiler have the same bit pattern). This is basically a HP-UX/PA-RISC bug:

{noformat}
$ cat t.cpp && gmake t && ./t
#include <cassert>
#include <climits>
#include <iostream>
#include <limits>

#include <math.h>

void pbits (const void *pobj, unsigned size)
{
    const unsigned char *pbits = (const unsigned char*)pobj;

    for (unsigned i = 0; i != size; ++i, ++pbits) {
        for (unsigned j = 0, bitno = 0; j != CHAR_BIT; ++j, ++bitno)
            std::cout << !!(*pbits & (1 << bitno));
        std::cout << ' ';
    }
    std::cout << '\n';
}


int main ()
{
    const double       qnan = std::numeric_limits<double>::quiet_NaN ();
    const double       nqnan = -qnan;
    const long double lqnan = std::numeric_limits<long double>::quiet_NaN ();
    const long double lnqnan = -lqnan;

    std::cout << qnan << ": signbit = " << signbit (qnan) << ", "
              << nqnan << ": signbit = " << signbit (nqnan) << '\n'
              << lqnan << ": signbit = " << signbit (lqnan) << ", "
              << lnqnan << ": signbit = " << signbit (lnqnan) << '\n';

    pbits (&qnan, sizeof qnan);
    pbits (&nqnan, sizeof nqnan);

    pbits (&lqnan, sizeof lqnan);
    pbits (&lnqnan, sizeof lnqnan);
}
aCC -c  -D_RWSTDDEBUG   -mt -I/tmp_mnt/amd/devco/sebor/stdcxx/include -I/build/sebor/stdcxx-aCC-3.73-15D/include -I/tmp_mnt/amd/devco/sebor/stdcxx/tests/include -AA  -g +d  +DD64 +w +W392 +W655 +W684 +W818 +W819 +W849   t.cpp
aCC t.o -o t -L/build/sebor/stdcxx-aCC-3.73-15D/rwtest -lrwtest15D -AA +nostl -Wl,+s   -mt +DD64 -L/build/sebor/stdcxx-aCC-3.73-15D/lib  -Wl,+b/build/sebor/stdcxx-aCC-3.73-15D/lib:/build/sebor/stdcxx-aCC-3.73-15D/rwtest -lstd15D  -lm 
nan: signbit = 0, -nan: signbit = 1
nan: signbit = 0, nan: signbit = 0
11111110 00101111 00000000 00000000 00000000 00000000 00000000 00000000 
11111111 00101111 00000000 00000000 00000000 00000000 00000000 00000000 
11111110 11111111 00000010 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
11111110 11111111 00000010 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
{noformat}

Also as Dennis says, this works correctly on IPF. The output is below (although note that the sign produced by our iostreams seems to be inverted):

{noformat}
-nan: signbit = 1, nan: signbit = 0
-nan: signbit = 1, nan: signbit = 0
11111111 00011111 00000000 00000000 00000000 00000000 00000000 00000000 
11111110 00011111 00000000 00000000 00000000 00000000 00000000 00000000 
11111111 11111111 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
11111110 11111111 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
{noformat}

> [HP-UX 11.23] printf("%Lg", -NAN) formatted incorrectly
> -------------------------------------------------------
>
>                 Key: STDCXX-463
>                 URL: https://issues.apache.org/jira/browse/STDCXX-463
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: External
>         Environment: HP-UX 11.23 and prior
>            Reporter: Martin Sebor
>
> -------- Original Message --------
> Subject: HP-UX 11.23 printf("%Lg", -NAN) formatted incorrectly
> Date: Thu, 28 Jun 2007 19:34:32 -0600
> From: Martin Sebor <sebor@roguewave.com>
> Organization: Rogue Wave Software
> To: acxx@cup.hp.com
> Hi,
> On 11.23/PA, printf("%g") formats negative NaN correctly (by
> prepending the minus) but with "%Lg" it forgets the sign. On
> 11.31/IPF printf() works correctly. Are there plans to backport
> the fix to prior versions of HP-UX and/or PA?
> Thanks
> Martin
> $ cat t.cpp && aCC -AA t.cpp && ./a.out
> #include <assert.h>
> #include <stdio.h>
> #include <string.h>
> #include <limits>
> int main ()
> {
>     char nan [32];
>     char nnan [32];
>     char lnan [32];
>     char nlnan [32];
>     sprintf (nan, "%g", std::numeric_limits<double>::quiet_NaN ());
>     sprintf (nnan, "%g", -std::numeric_limits<double>::quiet_NaN ());
>     sprintf (lnan, "%Lg", std::numeric_limits<long double>::quiet_NaN ());
>     sprintf (nlnan, "%Lg", -std::numeric_limits<long double>::quiet_NaN ());
>     printf ("%s, %s\n%s, %s\n", nan, nnan, lnan, nlnan);
>     assert (0 == strcmp (nan, lnan));
>     assert (0 == strcmp (nnan, nlnan));
> }
> nan, -nan
> nan, nan
> Assertion failed: 0 == strcmp (nnan, nlnan), file t.cpp, line 21
> ABORT instruction (core dumped)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.