http://www.perlmonks.org?node_id=1044463

BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:

I just posted code to demonstrate a solution to Unpack an 8 bit unsigned char matrix.

Only after posting did I noticed that, despite it uses unpack template 'C*', it produces 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, rather than:

print unpack 'C*', '1234567890';; 49 50 51 52 53 54 55 56 57 48

And without having given it a great deal of thought or experiment, I cannot for the life of me explain why. Can you?


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".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re: A mystery? (s/split/unpack/)
by LanX (Saint) on Jul 15, 2013 at 22:25 UTC
    I heard the theme from twilight zone while reading the title.

    spooky...

    Cheers Rolf   xD

    ( addicted to the Perl Programming Language)

    update

    I'm no big packerista, but what is split 'C*' supposed to do?

    my @matrixX10 = map[ split 'C*', $_ ], unpack '(a10)*', $buffer

    did you intend another unpack ?

    DB<105> map [ unpack 'C*', $_] ,unpack '(a10)*', '12345678901234567 +890' => ( [49, 50, 51, 52, 53, 54, 55, 56, 57, 48], [49, 50, 51, 52, 53, 54, 55, 56, 57, 48], )
      did you intend another unpack ?

      Yes. (Cliché, but LOL!)


      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".
      In the absence of evidence, opinion is indistinguishable from prejudice.
Re: A mystery?
by vsespb (Chaplain) on Jul 15, 2013 at 23:06 UTC
    Interesting that it dies under Linux with empty $! (unless I replace sysread with read), even if I replace CRLF with LF.
      Interesting that it dies under Linux with empty $!

      I've no knowledge to address that.

      The only possibility that springs to mind is that *nix sysread really objects to being used on a filehandle that has previously been used in "formatted IO" mode.

      Ie. As the DATA pseudo-handle is actually the same handle used to read the source, which presumably reads it using formatted IO, trying to read it with low-level IO sysread() causes it to throw its hands up in disgust :)

      even if I replace CRLF with LF.

      sysread should be completely oblivious to CRLF/LF -- even if I was asking it to read one or more -- but I'm asking it to read 80 characters only, so there are no newlines (of any flavour) being read.


      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".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        Works for me (Linux) if I prepend sysread() with

        binmode( DATA );