Lesson Learned: not all 32b perls are created equal

[pryrt]

Given the pretty CPAN Testers Christmas Tree, especially in the *BSD columns, I learned that not all 32-bit perls are created equal. After some more debug, I was able to show that it was those 32-bit perls with $Config{ivsize}==4 (32bit integers; aka perl -V:ivsize) that were failing, but those with $Config{ivsize}==8 (64bit integers in 32bit perl) would pass.

I had assumed (without looking) that the default ivsize on the 32bit perl was 4 bytes (32 bits), so thought that I had already tested and verified my IV weren't overflowing (or, if they were, they were promoting to NV). After seeing the problem, I discovered that when using left-shift, it would go from IV to NV... but it didn't. However, *=2 did promote the way I expected:

<Reveal this spoiler or all in this thread>

Conclusion: when doing a testing suite across versions, it's not always enough to just have a "32bit perl"; especially if you are dependent on integer sizes, also check that your test suite includes multiple ivsize values.

[ikegami]

C doesn't provide operators to perform bitwise operations on floats (because processors don't provide those either), and Perl doesn't go out of its way to add support for that.

It did recently add support for hexadecimal floats, though!

$ perl -e'CORE::say sprintf "%a", 9/10'
0x1.ccccccccccccdp-1

$ perl -e'CORE::say 0x1.ccccccccccccdp-1'
0.9

[pryrt]

It was a case of subconsciously expecting DWIM, and since it passed my 100%-coverage tests with 32bit perl, I thought it did DWIM

Yes, I saw the %a soon after releasing that project... defonitely a welcome addition. Some day, I might have my module use the builtin on modern perls, but I'll have to see whether it has all the features I want...