Re: Is the documentation for Perl 5.20 'pack' correct?

I'd concur that the docs are misleading, if not outright wrong:

#! perl -slw
use strict;
use Inline C => Config => BUILD_NOISY => 1;
use Inline C => <<'END_C',  NAME => 'Endian', CLEAN_AFTER_BUILD =>0;

SV *hexDump( UV in ) {
    int i;
    char *p = (char*)&in;
    SV *out = newSVpvn( NULL, 0 );

    for( i=0; i<8; ++i ) {
        sv_catpvf( out, "%02x", p[i] );
    }
    return out;
}

END_C

print hexDump( 72623859790382856 );

__END__
C:\test>endian
Use of uninitialized value in subroutine entry at C:\test\endian.pl li
+ne 19.
0807060504030201
[download]

(Aside: If anyone groks why I get the uninitialized value in subroutine entry warning; please enlighten me?)

But you have to factor in the context and tools you use to display the results.

For example, the first two below clearly demonstrate big and little endian respectively; the rest show how easy it is to get misleading results:


C:\test>p1
[0] Perl> print unpack 'C*', pack 'Q>', 72623859790382856;;
1 2 3 4 5 6 7 8

[0] Perl> print unpack 'C*', pack 'Q<', 72623859790382856;;
8 7 6 5 4 3 2 1

[0] Perl> print unpack 'H*', pack 'Q<', 72623859790382856;;
0807060504030201

[0] Perl> print unpack 'h*', pack 'Q<', 72623859790382856;;
8070605040302010

[0] Perl> print unpack 'H*', pack 'Q>', 72623859790382856;;
0102030405060708

[0] Perl> print unpack 'h*', pack 'Q>', 72623859790382856;;
1020304050607080

[0] Perl> print unpack 'b*', pack 'Q>', 72623859790382856;;
10000000 01000000 11000000 00100000 10100000 01100000 11100000 0001000
+0

[0] Perl> print unpack 'B*', pack 'Q>', 72623859790382856;;
00000001 00000010 00000011 00000100 00000101 00000110 00000111 0000100
+0

[0] Perl> print unpack 'b*', pack 'Q<', 72623859790382856;;
00010000 11100000 01100000 10100000 00100000 11000000 01000000 1000000
+0

[0] Perl> print unpack 'B*', pack 'Q<', 72623859790382856;;
00001000 00000111 00000110 00000101 00000100 00000011 00000010 0000000
+1
[download]

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.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Comment on Re: Is the documentation for Perl 5.20 'pack' correct? Select or Download Code

Replies are listed 'Best First'.
Re^2: Is the documentation for Perl 5.20 'pack' correct? by syphilis (Archbishop) on Jul 07, 2015 at 02:06 UTC
(Aside: If anyone groks why I get the uninitialized value in subroutine entry warning; please enlighten me?) Can't say that I actually grok it, but if you remove the sv_catpvf() call it goes away. Cheers, Rob	[reply]
Re^3: Is the documentation for Perl 5.20 'pack' correct? by BrowserUk (Patriarch) on Jul 07, 2015 at 07:20 UTC
Okay. I found a way to make it go away. Initialising `out` silences the warning: `#! perl -slw use strict; use Inline C => Config => BUILD_NOISY => 1; use Inline C => <<'END_C', NAME => 'Endian', CLEAN_AFTER_BUILD =>0; SV hexDump( UV in ) { int i; char p = (char)&in; SV out = newSVpvn( "?", 1 ); for( i=0; i<8; ++i ) { sv_catpvf( out, "%02x", p[i] ); } return out; } END_C print hexDump( 72623859790382856 ); __END__ C:\test>endian ?0807060504030201` [download] Which I guess means that the doc for newSVpvn() that reads:"If the s argument is NULL the new SV will be undefined. means something different to what I took it to mean. This also works: `SV hexDump( UV in ) { int i; char p = (char)&in; SV out = newSVpvn( "", 0 ); for( i=0; i<8; ++i ) { sv_catpvf( out, "%02x", p[i] ); } return out; }` [download] 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. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply] [d/l] [select]
Re^2: Is the documentation for Perl 5.20 'pack' correct? by ikegami (Patriarch) on Jul 07, 2015 at 00:08 UTC
Did you actually read the docs? We're talking about `perl -V:byteorder`.	[reply] [d/l]
Re^3: Is the documentation for Perl 5.20 'pack' correct? by flexvault (Monsignor) on Jul 07, 2015 at 15:46 UTC
ikegami, With all due respect, the topic is not about Perl's definition of byteorder, but the definition of and examples for little-endian and big-endian in the on-line documentation for Perl's 'pack' function. Perl's byteorder is academic! Please see the following from a RS/6000 with AIX 5.2 operating system: pyrperl -v `This is perl 5, version 12, subversion 2 (v5.12.2) built for aix Copyright 1987-2010, Larry Wall Perl may be copied only under the terms of either the Artistic License + or the GNU General Public License, which may be found in the Perl 5 source ki +t. Complete documentation for Perl, including FAQ lists, should be found +on this system using "man perl" or "perldoc perl". If you have access to + the Internet, point your browser at http://www.perl.org/, the Perl Home Pa +ge.` [download] and pyrperl -V:byteorder `byteorder='4321';` [download] and pyrperl -e '$p=pack("N",16909060); print unpack("H8",$p),"\n";' `01020304` [download] Until now, I did not know that the RS/6000 has a software switch on the motherboard to indicate running in little-endian or big-endian. When I read the Camel book, and it said that the "N" parameter of 'pack' put the result in Network or big-endian format, I knew what that meant and it didn't have an example. My original problem was with the on-line documentation. In goggling this, many authors seem to be guessing! Regards...Ed "Well done is better than well said." - Benjamin Franklin	[reply] [d/l] [select]