Re^7: Why is pack("N",42949672965) giving me 00 00 00 05

[ikegami]

pack takes a bunch of bits and interprets them in whatever way you tell if to

That's what unpack does, as you demonstrated. pack, on the other hand, is very specific about what it takes.

Passing negative numbers where an unsigned one is expected currently performs a C cast, but it's undocumented behaviour.

Neither I nor Perl can see any difference

To see the difference between using 0xFFFF_FFFF and -1, you just had to substitute 0xFFFF_FFFF for -1 instead of writing an entirely new program. Try again.

[BrowserUk]

Still no difference!:

print pack('N', -1) eq pack('N', 0xffff_ffff) ? 'Same' : 'Different';;
Same

print pack('N', -1) eq pack('N', 0xFFFF_FFFF) ? 'Same' : 'Different';;
Same

With the rise and rise of

[soonix]

ikegami most probably wants to point out the fact that, with a 'Q' specifier, 0xFFFF_FFFF will give a different result.

While you are certainly right that for "all F's" it is easier to write "one short of overflow", hence "-1", he is certainly right in pointing out that simply going from 0xFFFF_FFFF to 0xFFFF_FFFF_FFFF_FFFF may be an incorrect oversimplification.

[BrowserUk]

ikegami most probably wants to point out the fact that, with a 'Q' specifier, 0xFFFF_FFFF will give a different result.

Hm. But that isn't what he said!

What he said was: "your very question demonstrates that -1 and 0xFFFF_FFFF pack differently.". Which is patently and demonstrably wrong.

And I don't see any mention of using OxFFFF_FFFF in conjunction with the Q specifier in Tux post.

Indeed Tux didn't use, nor advocate the use of 0xFFFF_FFFF at all. The whole point of his post was: "Why not simply use -1?" which he demonstrated did the right thing with both 'N' & 'Q'.