Date: Thu, 16 Mar 2000 17:57:54 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc: djgpp-workers AT delorie DOT com,
        Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
Subject: Re: Unnormals???
In-Reply-To: <Pine.LNX.4.10.10003161442441.22148-100000@acp3bf>
Message-ID: <Pine.SUN.3.91.1000316174958.5735K-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Thu, 16 Mar 2000, Hans-Bernhard Broeker wrote:

> > > But the sign of a negative nan and inf should be printed regardless of
> > > any sign format specifier.
> > 
> > Why ``should''?  I don't think the standard says that, since some
> > architectures don't support signed NaNs.
> 
> That doesn't really matter. To cite the draft C99, on the '+'
> option to printf format specs:

We do comply with the standard when `+' is in the format.  I was 
referring to the case when it isn't, since Martin said ``regardless of 
any sign specifier''.

>        +     The result of a signed conversion always begins with a
>              plus or minus sign.  (It begins with a sign only  when
>              a  negative  value  is  converted  if this flag is not
>              specified.)258)

So on the architecture which doesn't know about the sign of a NaN, it 
will be printed with a plus.

>        258The results of all floating  conversions  of  a  negative
>           zero,  and of negative values that round to zero, include
>           a minus sign.
> 
> So, if a particular NaN is 'a negative value', it should have a minus in
> front of it.

That's the crux of the problem: the Intel (probably also IEEE) definition 
of a NaN includes the sign bit set.  Following the standard to the letter 
would disallow positive NaNs.

On the other hand, the standard does not specify the bit pattern for the 
NaN (obviously, it can't, without destroying portability).  So we are in 
the gray area between the machine representation and the standard.

> And just to bring that into the discussion, again: *printf() is not the
> only place we'ld have to have to do something about, here.
> "[-]nan(optional_string)" is supposed to be usable by other functions,
> too, including *scanf(), strtod and the new nan*() functions.

So what would you suggest to be produced by nan()?  Will the result have 
the sign bit set or not?  What about the expression "-nan()"?  And how 
all of these cases will be printed by printf, with or without the `+' in 
the format specifier?

These are the practical questions that bothered us when we discussed the 
issue about a year ago.