Front page | perl.perl5.porters |
Postings from October 2013
On Tue, Oct 29, 2013 at 10:06:30AM +0100, Lukas Mai wrote:
> On 29.10.2013 10:00, slaven@rezic.de (via RT) wrote:
> > # New Ticket Created by slaven@rezic.de
> > # Please include the string: [perl #120405]
> > # in the subject line of all future correspondence about this issue.
> > # <URL: https://rt.perl.org/Ticket/Display.html?id=120405 >
> >
> >
> > The problem is described in the StackOverflow article http://stackoverflow.com/questions/18969702/perl-strange-behaviour-on-unpack-of-floating-value
>
> Short version (copied into this bug for easier access):
> -----------------------------------------------------------------------
>
> $ perl -e "print unpack('f>', pack ('f>', 279.117156982422));"
> 279.617156982422
I don't reproduce this here on Debian stable:
tony@mars:.../git/bse$ ~/perl/5.18.0-thr/bin/perl -le "print unpack('f>', pack ('f>', 279.117156982422));"
279.117156982422
tony@mars:.../git/bse$ perl -le "print unpack('f>', pack ('f>', 279.117156982422));"
279.117156982422
perl -V output might be useful.
> Definitely a bug in Perl's unpacking. It has difficulty in handling
> floats in the binary form xxxxyyFF at least in a 32-bit platform, where
> 80 <= yy <= BF. The packed result will become xxxxzzFF, where zz = yy +
> 40 (all in hexadecimal). And this is not a problem of endianness, as you
> could see here:
>
> $ perl -e "print unpack('H8', pack ('f', unpack('f', pack('H8',
> '000088ff'))));";
> 0000c8ff
I'm pretty sure this isn't a bug, but the FPU converting a signalling
NaN into a quiet NaN, which the Intel CPU manual implies it does.
ie. this might happen when the float from pack() is converted into
double or long double, whichever representation perl uses for an NV.
That said, the compiler might be depending on aliasing rules and
loading afloat into an FPU register early, changing that code to use a
union as was done in 275663fa07 for NVs might fix the problem.
Tony
Thread Previous
|
Thread Next