in reply to pack on unpack with same template

Are there special cases of any sort (e.g. different environments, architectures) where the pack/unpack achieve anything different ?

I don't know of any such examples wrt to the U0C* template.
But I'm pretty unknowledgeable when it comes to Unicode, so I likely wouldn't know anyway ;-)

In general, there are some instances where pack($template, $scalar) will lose information that unpack() has no hope of restoring.
For example, on a perl whose $Config{nvsize} is greater than $Config{doublesize}: 
>perl -wle "print 'ok' if 2.3 != unpack 'd', pack 'd', 2.3;"
ok

[download]
A similar thing could happen with the I or i templates on a perl whose $Config{ivsize} is greater than $Config{intsize}.

Cheers,
Rob

Replies are listed 'Best First'.
Re^2: pack on unpack with same template
by kcott (Archbishop) on Jul 28, 2021 at 04:54 UTC

    Just as a confirmation (changed != to == and swapped the quotes around for *nix command line): 

    $ perl -wle 'print "ok" if 2.3 == unpack "d", pack "d", 2.3;'
ok

    [download]

    — Ken

[reply]
[d/l]
[select]
      Just as a confirmation (changed != to == ....

      Yes, if nvsize <= doublesize (not that nvsize is ever less than doublesize) then the equality holds.
      Otherwise the equality doesn't hold.

      ... and swapped the quotes around for *nix command line

      That was actually unneeded. (No big deal ... just FYI.)
      The rendition that I posted works fine on both Linux and windows.
      Perl one-liners inside double-quotes generally aren't a problem on Linux unless there's a scalar variable in the code - and I deliberately crafted my one-liner without inclusion of a scalar variable in order to achieve that portability ;-)

      Cheers,
      Rob
[reply]
        Perl one-liners inside double-quotes generally aren't a problem on Linux unless there's a scalar variable in the code - and I deliberately crafted my one-liner without inclusion of a scalar variable in order to achieve that portability ;-)

        You were also careful to ensure (or just lucky) that your code did not contain any of the default history control characters in a valid combination: !, ^ and #. These can vary from shell to shell and can (in many shells) be changed to other characters by the user. Try some of these rather contrived examples which will work if single quotes are used instead:

        • perl -E "say q/Hello!/"
        • perl -E "say q/Hello!!/"
        • perl -E "say q/found/ if shift =~ /^foo[^!#]/" foobar

        IMHO there is no reason not to use single quotes to delimit the entire script on the command line in any non-MSWin32 system and it is almost always the better choice where shell interpolation is not expressly intended.

        🦛

[reply]
[d/l]
[select]
        "That was actually unneeded. (No big deal ... just FYI.) ..."

        Well, that surprised me but it seems you are quite correct: 

        $ perl -e "print 'qwe'"
qwe

$ perl -e "my $x = 'qwe'; print $x"
syntax error at -e line 1, near "my  ="
Execution of -e aborted due to compilation errors.

        [download]

        I've had so much trouble with perl -e "..." in the past, that I now just automatically write perl -e '...', without giving it a second thought. I suppose my one-liners usually have a variable. Anyway, good to know; although, my muscle memory may take some convincing. :-)

        — Ken

[reply]
[d/l]
[select]
Re^2: pack on unpack with same template
by jjmoka (Beadle) on Jul 28, 2021 at 06:46 UTC
    Nice, thanks.
[reply]

In Section Seekers of Perl Wisdom