Mail Archives: djgpp-workers/2013/03/13/16:02:41
Am 11.03.2013 17:24, schrieb Martin Str�mberg:
[snip]
> Now over to the NaNs.
>
> Just because Linux's libc does one thing, it's not automatically the
> right/best/whatever way to do it.
>
> While the sign of the NaN might help to diagnose what went wrong it's
> not enough. Preferably _all_ the bits of the NaN should be presented.
>
> IIRC, that is allowed, but it been a while since I was messing with
> this. I thought I did it for DJGPP, but I can't see anything in the
> code about that, or perhaps I'm looking at the wrong places. It can be
> that I never finished it so I didn't send it. Or perhaps it was just
> for my own debugging I was messing with NaNs.
>
> Anyway, IIRC you are allowed to print "NaN(some representation of the
> bits of the NaN)" when you print a NaN as long as your *scanf() accept
> it as well.
>
> So I suggest if you really want to make the printing of NaNs better do
> that.
>
> My plan was to just dump the bits of the whole floating point number
> (just be make implementing it easy), something like (pseudocode)
>
> print_double(double d) {
> if( isnan(d) ) {
> printf("NaN(0x%x)", (unsigned long long)d);
> } else {
> printf("%d", d);
> }
> }
>
> scanf_double(char string, double *d_p) {
> unsinged long long ull;
> if( 1 == sscanf(string, "NaN(%llx)", &ull ) {
> ull |= 0x<whatever bits that must be set to make a NaN>;
> *d_p = *(double *)&ull;
> } elsif( 1 == sscanf(string, "nan(%llx)", &ull ) {
> /* Same as above. */
> } elsif( X == sscanf(string, <more variations of NaN> ...) {
> ...
> }
> }
>
> With that you can forget about the sign as you'll see that by looking
> at the bit patterns. And it sure is much better than what you're
> trying to copy from Linux's libc.
>
> I just don't see the point of printing only the sign and not the other
> interesting bits (the mantissa IIRC).
I have decided to revert the change I have committed some time ago. I
have run
the same test programs with cygwin and they do not print any sign. What you
are proposing sounds interesting but I do not think that the hassle to
implement that is worth, if the issue is not really required. I do not have
the time to implement it. Of course, you are welcome to provide an
implementation
if you like. I have done this patch for the sign behavior because I
have assumed
that the way linux behave was the correct way.
Regards,
Juan M. Guerrero
Index: djgpp/src/libc/ansi/stdio/doprnt.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/ansi/stdio/doprnt.c,v
retrieving revision 1.33
diff -U 5 -r1.33 doprnt.c
--- djgpp/src/libc/ansi/stdio/doprnt.c 5 Mar 2013 19:42:48 -0000 1.33
+++ djgpp/src/libc/ansi/stdio/doprnt.c 13 Mar 2013 19:57:27 -0000
@@ -388,11 +388,11 @@
}
else
{
ieee_value.ld = _ldouble;
- if (ieee_value.ldt.sign && !IS_NAN(ieee_value) &&
!IS_PSEUDO_NUMBER(ieee_value))
+ if (ieee_value.ldt.sign)
{
neg_ldouble = true;
if (IS_ZERO(ieee_value))
softsign = '-';
}
- Raw text -