perlpacktut.1

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

C structures:
.PP
.Vb 6
\&   typedef struct {
\&     char     c1;
\&     short    s;
\&     char     c2;
\&     long     l;
\&   } gappy_t;
\&
\&   typedef struct {
\&     long     l;
\&     short    s;
\&     char     c1;
\&     char     c2;
\&   } dense_t;
.Ve
.PP
Typically, a C compiler allocates 12 bytes to a \f(CW\*(C`gappy_t\*(C'\fR variable, but
requires only 8 bytes for a \f(CW\*(C`dense_t\*(C'\fR. After investigating this further,
we can draw memory maps, showing where the extra 4 bytes are hidden:
.PP
.Vb 5
\&   0           +4          +8          +12
\&   +\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+
\&   |c1|xx|  s  |c2|xx|xx|xx|     l     |    xx = fill byte
\&   +\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+
\&   gappy_t
\&
\&   0           +4          +8
\&   +\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+
\&   |     l     |  h  |c1|c2|
\&   +\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+\-\-+
\&   dense_t
.Ve
.PP
And that's where the first quirk strikes: \f(CW\*(C`pack\*(C'\fR and \f(CW\*(C`unpack\*(C'\fR
templates have to be stuffed with \f(CW\*(C`x\*(C'\fR codes to get those extra fill bytes.
.PP
The natural question: \*(L"Why can't Perl compensate for the gaps?\*(R" warrants
an answer. One good reason is that C compilers might provide (non-ANSI)
extensions permitting all sorts of fancy control over the way structures
are aligned, even at the level of an individual structure field. And, if
this were not enough, there is an insidious thing called \f(CW\*(C`union\*(C'\fR where
the amount of fill bytes cannot be derived from the alignment of the next
item alone.
.PP
\&\s-1OK\s0, so let's bite the bullet. Here's one way to get the alignment right
by inserting template codes \f(CW\*(C`x\*(C'\fR, which don't take a corresponding item 
from the list:
.PP
.Vb 1
\&  my $gappy = pack( \*(Aqcxs cxxx l!\*(Aq, $c1, $s, $c2, $l );
.Ve
.PP
Note the \f(CW\*(C`!\*(C'\fR after \f(CW\*(C`l\*(C'\fR: We want to make sure that we pack a long
integer as it is compiled by our C compiler. And even now, it will only
work for the platforms where the compiler aligns things as above.
And somebody somewhere has a platform where it doesn't.
[Probably a Cray, where \f(CW\*(C`short\*(C'\fRs, \f(CW\*(C`int\*(C'\fRs and \f(CW\*(C`long\*(C'\fRs are all 8 bytes. :\-)]
.PP
Counting bytes and watching alignments in lengthy structures is bound to 
be a drag. Isn't there a way we can create the template with a simple
program? Here's a C program that does the trick:
.PP
.Vb 2
\&   #include <stdio.h>
\&   #include <stddef.h>
\&
\&   typedef struct {
\&     char     fc1;
\&     short    fs;
\&     char     fc2;
\&     long     fl;
\&   } gappy_t;
\&
\&   #define Pt(struct,field,tchar) \e
\&     printf( "@%d%s ", offsetof(struct,field), # tchar );
\&
\&   int main() {
\&     Pt( gappy_t, fc1, c  );
\&     Pt( gappy_t, fs,  s! );
\&     Pt( gappy_t, fc2, c  );
\&     Pt( gappy_t, fl,  l! );
\&     printf( "\en" );
\&   }
.Ve
.PP
The output line can be used as a template in a \f(CW\*(C`pack\*(C'\fR or \f(CW\*(C`unpack\*(C'\fR call:
.PP
.Vb 1
\&  my $gappy = pack( \*(Aq@0c @2s! @4c @8l!\*(Aq, $c1, $s, $c2, $l );
.Ve
.PP
Gee, yet another template code \- as if we hadn't plenty. But 
\&\f(CW\*(C`@\*(C'\fR saves our day by enabling us to specify the offset from the beginning
of the pack buffer to the next item: This is just the value
the \f(CW\*(C`offsetof\*(C'\fR macro (defined in \f(CW\*(C`<stddef.h>\*(C'\fR) returns when
given a \f(CW\*(C`struct\*(C'\fR type and one of its field names (\*(L"member-designator\*(R" in 
C standardese).
.PP
Neither using offsets nor adding \f(CW\*(C`x\*(C'\fR's to bridge the gaps is satisfactory.
(Just imagine what happens if the structure changes.) What we really need
is a way of saying \*(L"skip as many bytes as required to the next multiple of N\*(R".
In fluent Templatese, you say this with \f(CW\*(C`x!N\*(C'\fR where N is replaced by the
appropriate value. Here's the next version of our struct packaging:
.PP
.Vb 1
\&  my $gappy = pack( \*(Aqc x!2 s c x!4 l!\*(Aq, $c1, $s, $c2, $l );
.Ve
.PP
That's certainly better, but we still have to know how long all the
integers are, and portability is far away. Rather than \f(CW2\fR,
for instance, we want to say \*(L"however long a short is\*(R". But this can be
done by enclosing the appropriate pack code in brackets: \f(CW\*(C`[s]\*(C'\fR. So, here's
the very best we can do:
.PP
.Vb 1
\&  my $gappy = pack( \*(Aqc x![s] s c x![l!] l!\*(Aq, $c1, $s, $c2, $l );
.Ve
.Sh "Dealing with Endian-ness"
.IX Subsection "Dealing with Endian-ness"
Now, imagine that we want to pack the data for a machine with a
different byte-order. First, we'll have to figure out how big the data
types on the target machine really are. Let's assume that the longs are
32 bits wide and the shorts are 16 bits wide. You can then rewrite the
template as:
.PP
.Vb 1
\&  my $gappy = pack( \*(Aqc x![s] s c x![l] l\*(Aq, $c1, $s, $c2, $l );
.Ve
.PP
If the target machine is little-endian, we could write:
.PP
.Vb 1
\&  my $gappy = pack( \*(Aqc x![s] s< c x![l] l<\*(Aq, $c1, $s, $c2, $l );
.Ve
.PP
This forces the short and the long members to be little-endian, and is
just fine if you don't have too many struct members. But we could also
use the byte-order modifier on a group and write the following:
.PP
.Vb 1
\&  my $gappy = pack( \*(Aq( c x![s] s c x![l] l )<\*(Aq, $c1, $s, $c2, $l );
.Ve
.PP
This is not as short as before, but it makes it more obvious that we
intend to have little-endian byte-order for a whole group, not only
for individual template codes. It can also be more readable and easier
to maintain.
.Sh "Alignment, Take 2"
.IX Subsection "Alignment, Take 2"
I'm afraid that we're not quite through with the alignment catch yet. The
hydra raises another ugly head when you pack arrays of structures:
.PP
.Vb 4
\&   typedef struct {
\&     short    count;
\&     char     glyph;
\&   } cell_t;
\&
\&   typedef cell_t buffer_t[BUFLEN];
.Ve
.PP
Where's the catch? Padding is neither required before the first field \f(CW\*(C`count\*(C'\fR,
nor between this and the next field \f(CW\*(C`glyph\*(C'\fR, so why can't we simply pack
like this:
.PP
.Vb 3
\&   # something goes wrong here:
\&   pack( \*(Aqs!a\*(Aq x @buffer,
\&         map{ ( $_\->{count}, $_\->{glyph} ) } @buffer );
.Ve
.PP
This packs \f(CW\*(C`3*@buffer\*(C'\fR bytes, but it turns out that the size of 
\&\f(CW\*(C`buffer_t\*(C'\fR is four times \f(CW\*(C`BUFLEN\*(C'\fR! The moral of the story is that
the required alignment of a structure or array is propagated to the
next higher level where we have to consider padding \fIat the end\fR
of each component as well. Thus the correct template is:
.PP
.Vb 2
\&   pack( \*(Aqs!ax\*(Aq x @buffer,
\&         map{ ( $_\->{count}, $_\->{glyph} ) } @buffer );
.Ve
.Sh "Alignment, Take 3"
.IX Subsection "Alignment, Take 3"
And even if you take all the above into account, \s-1ANSI\s0 still lets this:
.PP
.Vb 3
\&   typedef struct {
\&     char     foo[2];
\&   } foo_t;
.Ve
.PP
vary in size. The alignment constraint of the structure can be greater than
any of its elements. [And if you think that this doesn't affect anything
common, dismember the next cellphone that you see. Many have \s-1ARM\s0 cores, and
the \s-1ARM\s0 structure rules make \f(CW\*(C`sizeof (foo_t)\*(C'\fR == 4]
.Sh "Pointers for How to Use Them"
.IX Subsection "Pointers for How to Use Them"
The title of this section indicates the second problem you may run into
sooner or later when you pack C structures. If the function you intend
to call expects a, say, \f(CW\*(C`void *\*(C'\fR value, you \fIcannot\fR simply take
a reference to a Perl variable. (Although that value certainly is a
memory address, it's not the address where the variable's contents are
stored.)
.PP
Template code \f(CW\*(C`P\*(C'\fR promises to pack a \*(L"pointer to a fixed length string\*(R".
Isn't this what we want? Let's try:
.PP
.Vb 3
\&    # allocate some storage and pack a pointer to it
\&    my $memory = "\ex00" x $size;
\&    my $memptr = pack( \*(AqP\*(Aq, $memory );
.Ve
.PP
But wait: doesn't \f(CW\*(C`pack\*(C'\fR just return a sequence of bytes? How can we pass this
string of bytes to some C code expecting a pointer which is, after all,
nothing but a number? The answer is simple: We have to obtain the numeric
address from the bytes returned by \f(CW\*(C`pack\*(C'\fR.
.PP
.Vb 1
\&    my $ptr = unpack( \*(AqL!\*(Aq, $memptr );
.Ve
.PP
Obviously this assumes that it is possible to typecast a pointer
to an unsigned long and vice versa, which frequently works but should not
be taken as a universal law. \- Now that we have this pointer the next question
is: How can we put it to good use? We need a call to some C function
where a pointer is expected. The \fIread\fR\|(2) system call comes to mind:
.PP
.Vb 1
\&    ssize_t read(int fd, void *buf, size_t count);
.Ve
.PP
After reading perlfunc explaining how to use \f(CW\*(C`syscall\*(C'\fR we can write
this Perl function copying a file to standard output:
.PP
.Vb 12
\&    require \*(Aqsyscall.ph\*(Aq;
\&    sub cat($){
\&        my $path = shift();
\&        my $size = \-s $path;
\&        my $memory = "\ex00" x $size;  # allocate some memory
\&        my $ptr = unpack( \*(AqL\*(Aq, pack( \*(AqP\*(Aq, $memory ) );
\&        open( F, $path ) || die( "$path: cannot open ($!)\en" );
\&        my $fd = fileno(F);
\&        my $res = syscall( &SYS_read, fileno(F), $ptr, $size );
\&        print $memory;
\&        close( F );
\&    }
.Ve
.PP
This is neither a specimen of simplicity nor a paragon of portability but
it illustrates the point: We are able to sneak behind the scenes and
access Perl's otherwise well-guarded memory! (Important note: Perl's
\&\f(CW\*(C`syscall\*(C'\fR does \fInot\fR require you to construct pointers in this roundabout
way. You simply pass a string variable, and Perl forwards the address.)
.PP
How does \f(CW\*(C`unpack\*(C'\fR with \f(CW\*(C`P\*(C'\fR work? Imagine some pointer in the buffer
about to be unpacked: If it isn't the null pointer (which will smartly
produce the \f(CW\*(C`undef\*(C'\fR value) we have a start address \- but then what?
Perl has no way of knowing how long this \*(L"fixed length string\*(R" is, so
it's up to you to specify the actual size as an explicit length after \f(CW\*(C`P\*(C'\fR.
.PP
.Vb 2
\&   my $mem = "abcdefghijklmn";
\&   print unpack( \*(AqP5\*(Aq, pack( \*(AqP\*(Aq, $mem ) ); # prints "abcde"
.Ve
.PP
As a consequence, \f(CW\*(C`pack\*(C'\fR ignores any number or \f(CW\*(C`*\*(C'\fR after \f(CW\*(C`P\*(C'\fR.
.PP
Now that we have seen \f(CW\*(C`P\*(C'\fR at work, we might as well give \f(CW\*(C`p\*(C'\fR a whirl.
Why do we need a second template code for packing pointers at all? The 
answer lies behind the simple fact that an \f(CW\*(C`unpack\*(C'\fR with \f(CW\*(C`p\*(C'\fR promises
a null-terminated string starting at the address taken from the buffer,
and that implies a length for the data item to be returned:
.PP
.Vb 2
\&   my $buf = pack( \*(Aqp\*(Aq, "abc\ex00efhijklmn" );
\&   print unpack( \*(Aqp\*(Aq, $buf );    # prints "abc"
.Ve
.PP
Albeit this is apt to be confusing: As a consequence of the length being
implied by the string's length, a number after pack code \f(CW\*(C`p\*(C'\fR is a repeat
count, not a length as after \f(CW\*(C`P\*(C'\fR.
.PP
Using \f(CW\*(C`pack(..., $x)\*(C'\fR with \f(CW\*(C`P\*(C'\fR or \f(CW\*(C`p\*(C'\fR to get the address where \f(CW$x\fR is
actually stored must be used with circumspection. Perl's internal machinery
considers the relation between a variable and that address as its very own 
private matter and doesn't really care that we have obtained a copy. Therefore:
.IP "\(bu" 4
Do not use \f(CW\*(C`pack\*(C'\fR with \f(CW\*(C`p\*(C'\fR or \f(CW\*(C`P\*(C'\fR to obtain the address of variable
that's bound to go out of scope (and thereby freeing its memory) before you
are done with using the memory at that address.
.IP "\(bu" 4
Be very careful with Perl operations that change the value of the
variable. Appending something to the variable, for instance, might require
reallocation of its storage, leaving you with a pointer into no-man's land.
.IP "\(bu" 4
Don't think that you can get the address of a Perl variable
when it is stored as an integer or double number! \f(CW\*(C`pack(\*(AqP\*(Aq, $x)\*(C'\fR will
force the variable's internal representation to string, just as if you
had written something like \f(CW\*(C`$x .= \*(Aq\*(Aq\*(C'\fR.
.PP
It's safe, however, to P\- or p\-pack a string literal, because Perl simply
allocates an anonymous variable.
.SH "Pack Recipes"
.IX Header "Pack Recipes"
Here are a collection of (possibly) useful canned recipes for \f(CW\*(C`pack\*(C'\fR
and \f(CW\*(C`unpack\*(C'\fR:
.PP
.Vb 2
\&    # Convert IP address for socket functions
\&    pack( "C4", split /\e./, "123.4.5.6" ); 
\&
\&    # Count the bits in a chunk of memory (e.g. a select vector)
\&    unpack( \*(Aq%32b*\*(Aq, $mask );
\&
\&    # Determine the endianness of your system
\&    $is_little_endian = unpack( \*(Aqc\*(Aq, pack( \*(Aqs\*(Aq, 1 ) );
\&    $is_big_endian = unpack( \*(Aqxc\*(Aq, pack( \*(Aqs\*(Aq, 1 ) );
\&
\&    # Determine the number of bits in a native integer
\&    $bits = unpack( \*(Aq%32I!\*(Aq, ~0 );
\&
\&    # Prepare argument for the nanosleep system call
\&    my $timespec = pack( \*(AqL!L!\*(Aq, $secs, $nanosecs );
.Ve
.PP
For a simple memory dump we unpack some bytes into just as 
many pairs of hex digits, and use \f(CW\*(C`map\*(C'\fR to handle the traditional
spacing \- 16 bytes to a line:
.PP
.Vb 4
\&    my $i;
\&    print map( ++$i % 16 ? "$_ " : "$_\en",
\&               unpack( \*(AqH2\*(Aq x length( $mem ), $mem ) ),
\&          length( $mem ) % 16 ? "\en" : \*(Aq\*(Aq;
.Ve
.SH "Funnies Section"
.IX Header "Funnies Section"
.Vb 5
\&    # Pulling digits out of nowhere...
\&    print unpack( \*(AqC\*(Aq, pack( \*(Aqx\*(Aq ) ),
\&          unpack( \*(Aq%B*\*(Aq, pack( \*(AqA\*(Aq ) ),
\&          unpack( \*(AqH\*(Aq, pack( \*(AqA\*(Aq ) ),
\&          unpack( \*(AqA\*(Aq, unpack( \*(AqC\*(Aq, pack( \*(AqA\*(Aq ) ) ), "\en";
\&
\&    # One for the road ;\-)
\&    my $advice = pack( \*(Aqall u can in a van\*(Aq );
.Ve
.SH "Authors"
.IX Header "Authors"
Simon Cozens and Wolfgang Laun.