perlhack.pod

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

Arguments are passed to PP code and returned from PP code using the
argument stack, C<ST>. The typical way to handle arguments is to pop
them off the stack, deal with them how you wish, and then push the result
back onto the stack. This is how, for instance, the cosine operator
works:

      NV value;
      value = POPn;
      value = Perl_cos(value);
      XPUSHn(value);

We'll see a more tricky example of this when we consider Perl's macros
below. C<POPn> gives you the NV (floating point value) of the top SV on
the stack: the C<$x> in C<cos($x)>. Then we compute the cosine, and push
the result back as an NV. The C<X> in C<XPUSHn> means that the stack
should be extended if necessary - it can't be necessary here, because we
know there's room for one more item on the stack, since we've just
removed one! The C<XPUSH*> macros at least guarantee safety.

Alternatively, you can fiddle with the stack directly: C<SP> gives you
the first element in your portion of the stack, and C<TOP*> gives you
the top SV/IV/NV/etc. on the stack. So, for instance, to do unary
negation of an integer:

     SETi(-TOPi);

Just set the integer value of the top stack entry to its negation.

Argument stack manipulation in the core is exactly the same as it is in
XSUBs - see L<perlxstut>, L<perlxs> and L<perlguts> for a longer
description of the macros used in stack manipulation.

=item Mark stack

I say "your portion of the stack" above because PP code doesn't
necessarily get the whole stack to itself: if your function calls
another function, you'll only want to expose the arguments aimed for the
called function, and not (necessarily) let it get at your own data. The
way we do this is to have a "virtual" bottom-of-stack, exposed to each
function. The mark stack keeps bookmarks to locations in the argument
stack usable by each function. For instance, when dealing with a tied
variable, (internally, something with "P" magic) Perl has to call
methods for accesses to the tied variables. However, we need to separate
the arguments exposed to the method to the argument exposed to the
original function - the store or fetch or whatever it may be. Here's
roughly how the tied C<push> is implemented; see C<av_push> in F<av.c>:

     1	PUSHMARK(SP);
     2	EXTEND(SP,2);
     3	PUSHs(SvTIED_obj((SV*)av, mg));
     4	PUSHs(val);
     5	PUTBACK;
     6	ENTER;
     7	call_method("PUSH", G_SCALAR|G_DISCARD);
     8	LEAVE;

Let's examine the whole implementation, for practice:

     1	PUSHMARK(SP);

Push the current state of the stack pointer onto the mark stack. This is
so that when we've finished adding items to the argument stack, Perl
knows how many things we've added recently.

     2	EXTEND(SP,2);
     3	PUSHs(SvTIED_obj((SV*)av, mg));
     4	PUSHs(val);

We're going to add two more items onto the argument stack: when you have
a tied array, the C<PUSH> subroutine receives the object and the value
to be pushed, and that's exactly what we have here - the tied object,
retrieved with C<SvTIED_obj>, and the value, the SV C<val>.

     5	PUTBACK;

Next we tell Perl to update the global stack pointer from our internal
variable: C<dSP> only gave us a local copy, not a reference to the global.

     6	ENTER;
     7	call_method("PUSH", G_SCALAR|G_DISCARD);
     8	LEAVE;

C<ENTER> and C<LEAVE> localise a block of code - they make sure that all
variables are tidied up, everything that has been localised gets
its previous value returned, and so on. Think of them as the C<{> and
C<}> of a Perl block.

To actually do the magic method call, we have to call a subroutine in
Perl space: C<call_method> takes care of that, and it's described in
L<perlcall>. We call the C<PUSH> method in scalar context, and we're
going to discard its return value.  The call_method() function
removes the top element of the mark stack, so there is nothing for
the caller to clean up.

=item Save stack

C doesn't have a concept of local scope, so perl provides one. We've
seen that C<ENTER> and C<LEAVE> are used as scoping braces; the save
stack implements the C equivalent of, for example:

    {
        local $foo = 42;
        ...
    }

See L<perlguts/Localising Changes> for how to use the save stack.

=back

=head2 Millions of Macros

One thing you'll notice about the Perl source is that it's full of
macros. Some have called the pervasive use of macros the hardest thing
to understand, others find it adds to clarity. Let's take an example,
the code which implements the addition operator:

   1  PP(pp_add)
   2  {
   3      dSP; dATARGET; tryAMAGICbin(add,opASSIGN);
   4      {
   5        dPOPTOPnnrl_ul;
   6        SETn( left + right );
   7        RETURN;
   8      }
   9  }

Every line here (apart from the braces, of course) contains a macro. The
first line sets up the function declaration as Perl expects for PP code;
line 3 sets up variable declarations for the argument stack and the
target, the return value of the operation. Finally, it tries to see if
the addition operation is overloaded; if so, the appropriate subroutine
is called.

Line 5 is another variable declaration - all variable declarations start
with C<d> - which pops from the top of the argument stack two NVs (hence
C<nn>) and puts them into the variables C<right> and C<left>, hence the
C<rl>. These are the two operands to the addition operator. Next, we
call C<SETn> to set the NV of the return value to the result of adding
the two values. This done, we return - the C<RETURN> macro makes sure
that our return value is properly handled, and we pass the next operator
to run back to the main run loop.

Most of these macros are explained in L<perlapi>, and some of the more
important ones are explained in L<perlxs> as well. Pay special attention
to L<perlguts/Background and PERL_IMPLICIT_CONTEXT> for information on
the C<[pad]THX_?> macros.

=head2 The .i Targets

You can expand the macros in a F<foo.c> file by saying

    make foo.i

which will expand the macros using cpp.  Don't be scared by the results.

=head1 SOURCE CODE STATIC ANALYSIS

Various tools exist for analysing C source code B<statically>, as
opposed to B<dynamically>, that is, without executing the code.
It is possible to detect resource leaks, undefined behaviour, type
mismatches, portability problems, code paths that would cause illegal
memory accesses, and other similar problems by just parsing the C code
and looking at the resulting graph, what does it tell about the
execution and data flows.  As a matter of fact, this is exactly
how C compilers know to give warnings about dubious code.

=head2 lint, splint

The good old C code quality inspector, C<lint>, is available in
several platforms, but please be aware that there are several
different implementations of it by different vendors, which means that
the flags are not identical across different platforms.

There is a lint variant called C<splint> (Secure Programming Lint)
available from http://www.splint.org/ that should compile on any
Unix-like platform.

There are C<lint> and <splint> targets in Makefile, but you may have
to diddle with the flags (see above).

=head2 Coverity

Coverity (http://www.coverity.com/) is a product similar to lint and
as a testbed for their product they periodically check several open
source projects, and they give out accounts to open source developers
to the defect databases.

=head2 cpd (cut-and-paste detector)

The cpd tool detects cut-and-paste coding.  If one instance of the
cut-and-pasted code changes, all the other spots should probably be
changed, too.  Therefore such code should probably be turned into a
subroutine or a macro.

cpd (http://pmd.sourceforge.net/cpd.html) is part of the pmd project
(http://pmd.sourceforge.net/).  pmd was originally written for static
analysis of Java code, but later the cpd part of it was extended to
parse also C and C++.

Download the pmd-bin-X.Y.zip () from the SourceForge site, extract the
pmd-X.Y.jar from it, and then run that on source code thusly:

  java -cp pmd-X.Y.jar net.sourceforge.pmd.cpd.CPD --minimum-tokens 100 --files /some/where/src --language c > cpd.txt

You may run into memory limits, in which case you should use the -Xmx option:

  java -Xmx512M ...

=head2 gcc warnings

Though much can be written about the inconsistency and coverage
problems of gcc warnings (like C<-Wall> not meaning "all the
warnings", or some common portability problems not being covered by
C<-Wall>, or C<-ansi> and C<-pedantic> both being a poorly defined
collection of warnings, and so forth), gcc is still a useful tool in
keeping our coding nose clean.

The C<-Wall> is by default on.

The C<-ansi> (and its sidekick, C<-pedantic>) would be nice to be on
always, but unfortunately they are not safe on all platforms, they can
for example cause fatal conflicts with the system headers (Solaris
being a prime example).  If Configure C<-Dgccansipedantic> is used,
the C<cflags> frontend selects C<-ansi -pedantic> for the platforms
where they are known to be safe.

Starting from Perl 5.9.4 the following extra flags are added:

=over 4

=item *

C<-Wendif-labels>

=item *

C<-Wextra>

=item *

C<-Wdeclaration-after-statement>

=back

The following flags would be nice to have but they would first need
their own Augean stablemaster:

=over 4

=item *

C<-Wpointer-arith>

=item *

C<-Wshadow>

=item *

C<-Wstrict-prototypes>

=back

The C<-Wtraditional> is another example of the annoying tendency of
gcc to bundle a lot of warnings under one switch -- it would be
impossible to deploy in practice because it would complain a lot -- but
it does contain some warnings that would be beneficial to have available
on their own, such as the warning about string constants inside macros
containing the macro arguments: this behaved differently pre-ANSI
than it does in ANSI, and some C compilers are still in transition,
AIX being an example.

=head2 Warnings of other C compilers

Other C compilers (yes, there B<are> other C compilers than gcc) often
have their "strict ANSI" or "strict ANSI with some portability extensions"
modes on, like for example the Sun Workshop has its C<-Xa> mode on
(though implicitly), or the DEC (these days, HP...) has its C<-std1>
mode on.

=head2 DEBUGGING

You can compile a special debugging version of Perl, which allows you
to use the C<-D> option of Perl to tell more about what Perl is doing.
But sometimes there is no alternative than to dive in with a debugger,
either to see the stack trace of a core dump (very useful in a bug
report), or trying to figure out what went wrong before the core dump
happened, or how did we end up having wrong or unexpected results.

=head2 Poking at Perl

To really poke around with Perl, you'll probably want to build Perl for
debugging, like this:

    ./Configure -d -D optimize=-g
    make

C<-g> is a flag to the C compiler to have it produce debugging
information which will allow us to step through a running program,
and to see in which C function we are at (without the debugging
information we might see only the numerical addresses of the functions,
which is not very helpful).

F<Configure> will also turn on the C<DEBUGGING> compilation symbol which
enables all the internal debugging code in Perl. There are a whole bunch
of things you can debug with this: L<perlrun> lists them all, and the
best way to find out about them is to play about with them. The most
useful options are probably

    l  Context (loop) stack processing
    t  Trace execution
    o  Method and overloading resolution
    c  String/numeric conversions

Some of the functionality of the debugging code can be achieved using XS
modules.

    -Dr => use re 'debug'
    -Dx => use O 'Debug'

=head2 Using a source-level debugger

If the debugging output of C<-D> doesn't help you, it's time to step
through perl's execution wit