* Rafael Laboissiere <raf...@debian.org> [2009-06-14 22:45]:
> Now, I am wondering whether the code in set_format() makes sense. The
> function reads:
>
> ///////////////////////////////////////////////////////////////////////////
> static void
> set_format (const Complex& c, int& r_fw, int& i_fw)
> {
> // [snip]
>
> double rp = c.real ();
> double ip = c.imag ();
>
> bool inf_or_nan = (xisinf (c) || xisnan (c));
>
> bool int_only = (D_NINT (rp) == rp && D_NINT (ip) == ip);
>
> double r_abs = rp < 0.0 ? -rp : rp;
> double i_abs = ip < 0.0 ? -ip : ip;
>
>
> int r_x = r_abs == 0.0
> ? 0 : static_cast<int> (floor (log10 (r_abs) + 1.0));
>
> // [snip]
> ///////////////////////////////////////////////////////////////////////////
>
> When r_abs is NaN (as in the bug-triggering case) what is the sense of
> computing log10 (r_abs) and propagating the result? I am probably
> missing something but it seems just pure chance that r_x ends up being
> negative on amd64 and i386, what does not trigger the bug.
Attached below is a patch for pr-output.cc that makes Octave work as
expected for 'complex(NaN,0)' on mips (and amd64 as well, FWIW). The
package is being built right now on mips and on amd64 and, if everything
goes well on both arches, I will upload to unstable a new version of the
package, octave3.2_3.2.0-2, containing the patch.
I am rushing with this because everything else is being held by this bug,
like the upload of the new octave-forge packages.
--
Rafael
--- a/pr-output.cc 2009-06-15 08:48:48.000000000 +0200
+++ b/pr-output.cc 2009-06-15 11:28:58.000000000 +0200
@@ -852,10 +852,12 @@
double i_abs = ip < 0.0 ? -ip : ip;
int r_x = r_abs == 0.0
- ? 0 : static_cast<int> (floor (log10 (r_abs) + 1.0));
+ ? 0 : ((xisinf (rp) || xisnan (rp))
+ ? INT_MIN : static_cast<int> (floor (log10 (r_abs) + 1.0)));
int i_x = i_abs == 0.0
- ? 0 : static_cast<int> (floor (log10 (i_abs) + 1.0));
+ ? 0 : ((xisinf (ip) || xisnan (ip))
+ ? INT_MIN : static_cast<int> (floor (log10 (i_abs) + 1.0)));
int x_max, x_min;
