X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Thu, 16 Mar 2000 17:46:25 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	djgpp workers list <djgpp-workers AT delorie DOT com>
Subject:	Re: Unnormals???
In-Reply-To:	<Pine.SUN.3.91.1000316174958.5735K-100000@is>
Message-ID:	<Pine.LNX.4.10.10003161706080.22148-100000@acp3bf>
MIME-Version:	1.0
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

On Thu, 16 Mar 2000, Eli Zaretskii wrote:
> 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''.

I didn't cite the standard because of the behaviour with '+' set, but
because of the second sentence. I'll underline it:

> >        +     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)
                 ^^^^^^^^^^

In other words: if the '+' option is not set, and the value is negative,
the output begins with a sign. The wording is a bit distracting because of
the word 'only' in it, but that's what I think this sentence says.

Applying this to a NaN means that a negative NaN should always have a
minus in front of it, on printout, regardless of any option to the
printf() format.

> That's the crux of the problem: the Intel (probably also IEEE) definition 
> of a NaN includes the sign bit set.  

Does it? My books both say that there are negative and positive NaNs, i.e.
the sign bit of a NaN is treated exactly like in all other FP numbers.
 
> So what would you suggest to be produced by nan()? Will the result have 
> the sign bit set or not?  

A positive NaN, as nan(string) is supposed to behave exactly as
strtod("NAN(string)"), i.e. there is no minus in front of it.

> What about the expression "-nan()"?  

Whatever the FPU usually does if you multiply a positive NaN by minus 1.
We don't have control over the execution of -nan() by the compiler, so we
have nothing to choose, here.

If the user wants a negative Nan, she should call strtod("-NAN") or
strtod("-NAN(string)"), respectively. strtod() may calculate its result as
-strtod("NAN)"), in turn, as far as C99 is concerned, but we could always
choose the more sensible direct path, here, or at even set the sign bit by
direct bit manipulation, instead of multiplying by -1.

> And how all of these cases will be printed by printf, with or without
> the `+' in the format specifier?

Exactly like with non-special numbers. The decision regarding '+' or '-'
sign output depends only on the sign bit of the number and the printf
format options chosen (' ', '+' or none of them), really. I don't see any
special treatment for NaN, Infinity or anything, here, neither in the
C standard, nor in my x87 hardware book.


Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -