Mail Archives: djgpp-workers/2000/03/16/09:49:43
On Thu, 16 Mar 2000, Eli Zaretskii wrote:
>
> On Wed, 15 Mar 2000, Martin Stromberg wrote:
>
> > > Perhaps you tried without the sign in the format specifier? That case
> > > was left alone on purpose; see the discussions on djgpp-workers about 10
> > > months ago (IIRC).
> >
> > 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:
+ 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)
and the footnote:
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. The syntax of describing a printf() output by "[-]something"
is used throughout the printf() definition, so I think there's no option
for interpreting "[-]nan" any different from the other cases, here.
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.
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -