[issue7281] copysign() with NaN arguments on OpenSolaris

Stefan Krah report at bugs.python.org
Sun Nov 8 14:49:13 CET 2009


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I hope this won't be getting too complex. :)

Firstly, I agree that this is perhaps not a bug at all. I reported it
because I seemed possible that Python2.x had a deliberate workaround for
this issue which somehow got lost in 3.x.

Secondly, I didn't mention that I'm running OpenSolaris on KVM since I
can't get it to install on physical hardware. However, I don't think KVM
plays a role here since gcc produces 'normal' results.

So, the problem combination is:

Ubuntu64bit -> KVM -> OpenSolaris32bit/suncc/Py3k


On the C level, here's an example:

#include <stdio.h>
#include <math.h>

int main(void)
{
        double x = NAN;
        printf("%f  %f\n", x, copysign(1.0, x));
        return 0;
}

This gives -NaN, -1.000000 with suncc and NaN, 1.000000 with gcc. 


Back to Python:

sys.float_repr_style is 'legacy'.

It looks like the C99 fenv functions are pretty much supported, but I
don't know since when. I found man pages from 2003 for fenv and from
2006 for the fe*() functions.

This for example works:

#include <stdio.h>
#include <stdio.h>
#include <fenv.h>
#include <assert.h>

int main(void)
{
        #pragma STDC FENV_ACCESS ON
        int save_round;
        int setround_ok;

        save_round = fegetround();

        setround_ok = fesetround(FE_DOWNWARD);
        assert(setround_ok == 0);

        fesetround(save_round);
}


I could test changes that you make (preferably in p3k head, so I could
just pull them). But as I said: If the 'proper' behavior in 2.x was not
a deliberate workaround, there's really no need to change anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7281>
_______________________________________


More information about the Python-bugs-list mailing list