[Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

[Rafael Laboissiere]

* Rafael Laboissiere <rafael at debian.org> [2009-06-14 15:39]:

> * Rafael Laboissiere <rafael at debian.org> [2009-06-14 12:25]:
> 
> > I think that the different values of x_max and x_min explain the bug on
> > the mips system.  I guess that this is caused by the following lines in
> > pr-output.cc (function set_format):
> > 
> >       int x_max = max_abs == 0.0                                                                                               
> >         ? 0 : static_cast<int> (floor (log10 (max_abs) + 1.0));                                                                
> >                                                                                                                            
> >       int x_min = min_abs == 0.0                                                                                               
> >         ? 0 : static_cast<int> (floor (log10 (min_abs) + 1.0));                                                                
> 
> I meant lines 854 to 858 in pr-output.cc, in function 
> set_format (const Complex& c, int& r_fw, int& i_fw)

I think I found the cause of the bug.  The simple program:

///////////////////////////////////////////////////////////////////////////
#include <cmath>
#include <iostream>

int
main (void)
{
    std::cerr << static_cast<int> (floor (log10 (0.0/0.0))) << std::endl;
    return 0;
}
///////////////////////////////////////////////////////////////////////////

when compiled on mips yields 2147483647, while on amd64 and i386 it
yields -2147483648.  This explains the different behavior on both
architectures.

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.

-- 
Rafael