in reply to Re: Character in 'b' format wrapped in unpack
in thread Character in 'b' format wrapped in unpack

when you pass a numeric value greater than 255 to chr, it must return a wide character.

There is no "must" about it. It should be the case that unless I specifically ask for Unicrap, characters should be assumed to be 8-bits.

I'm afraid I don't quite understand the reason(s) for what happens when the "use bytes" pragma is added -- if I've done it right, the only difference is to eliminate the warning message about the "wrapped character in unpack"

You're right. It does just enough to lull you into a false sense of security; then sneaks around behind and kicks you in the nuts!


Is it the case that you got the particular pattern of zeros and ones you expected, and were just complaining about the warning message?)

No. I wanted the shift to discard the high bit, as it does with integers:

$n <<= 1; print unpack 'B*', pack 'N', $n;; 10101011010101001010101101010100 $n <<= 1; print unpack 'B*', pack 'N', $n;; 01010110101010010101011010101000 $n <<= 1; print unpack 'B*', pack 'N', $n;; 10101101010100101010110101010000

Unfortunately, Unicrap (and Perl's implementation of Unicrap) conspire such that you can no longer rely upon simple byte semantics.

The idea that a string (a good old array of bytes) can suddenly contain a random Unicrap character in a program that doesn't (and doesn't want to) use any Unicrap, is a farce!

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked