right combination of C<const>s:
static const char * const yippee[] =
- {"hi", "ho", "silver"};
+ {"hi", "ho", "silver"};
There is a way to completely hide any modifiable globals (they are all
moved to heap), the compilation setting
If you need the string representation of a character that doesn't have a
mnemonic name in C, you should add it to the list in
-F<regen/unicode_constants.pl>, and have Perl create C<#define>s for you,
+F<regen/unicode_constants.pl>, and have Perl create C<#define>'s for you,
based on the current platform.
Note that the C<isI<FOO>> and C<toI<FOO>> macros in F<handy.h> work
Also, the range 'A' - 'Z' in ASCII is an unbroken sequence of 26 upper
case alphabetic characters. That is not true in EBCDIC. Nor for 'a' to
'z'. But '0' - '9' is an unbroken range in both systems. Don't assume
-anything about other ranges.
+anything about other ranges. (Note that special handling of ranges in
+regular expression patterns and transliterations makes it appear to Perl
+code that the aforementioned ranges are all unbroken.)
Many of the comments in the existing code ignore the possibility of
EBCDIC, and may be wrong therefore, even if the code works. This is
C<NATIVE_IS_INVARIANT()> macro appropriately, it works, even if the
comments are wrong.
+As noted in L<perlhack/TESTING>, when writing test scripts, the file
+F<t/charset_tools.pl> contains some helpful functions for writing tests
+valid on both ASCII and EBCDIC platforms. Sometimes, though, a test
+can't use a function and it's inconvenient to have different test
+versions depending on the platform. There are 20 code points that are
+the same in all 4 character sets currently recognized by Perl (the 3
+EBCDIC code pages plus ISO 8859-1 (ASCII/Latin1)). These can be used in
+such tests, though there is a small possibility that Perl will become
+available in yet another character set, breaking your test. All but one
+of these code points are C0 control characters. The most significant
+controls that are the same are C<\0>, C<\r>, and C<\N{VT}> (also
+specifiable as C<\cK>, C<\x0B>, C<\N{U+0B}>, or C<\013>). The single
+non-control is U+00B6 PILCROW SIGN. The controls that are the same have
+the same bit pattern in all 4 character sets, regardless of the UTF8ness
+of the string containing them. The bit pattern for U+B6 is the same in
+all 4 for non-UTF8 strings, but differs in each when its containing
+string is UTF-8 encoded. The only other code points that have some sort
+of sameness across all 4 character sets are the pair 0xDC and 0xFC.
+Together these represent upper- and lowercase LATIN LETTER U WITH
+DIAERESIS, but which is upper and which is lower may be reversed: 0xDC
+is the capital in Latin1 and 0xFC is the small letter, while 0xFC is the
+capital in EBCDIC and 0xDC is the small one. This factoid may be
+exploited in writing case insensitive tests that are the same across all
+4 character sets.
+
=item *
Assuming the character set is just ASCII
But in any case, try to keep the features and operating systems
separate.
+A good resource on the predefined macros for various operating
+systems, compilers, and so forth is
+L<http://sourceforge.net/p/predef/wiki/Home/>
+
=item *
Assuming the contents of static memory pointed to by the return values
(gdb) ptype PL_op
type = struct op {
OP *op_next;
- OP *op_sibling;
+ OP *op_sibparent;
OP *(*op_ppaddr)(void);
PADOFFSET op_targ;
unsigned int op_type : 9;
=head2 Using gdb to look at specific parts of a program
-With the example above, you knew to look for C<Perl_pp_add>, but what if
-there were multiple calls to it all over the place, or you didn't know what
+With the example above, you knew to look for C<Perl_pp_add>, but what if
+there were multiple calls to it all over the place, or you didn't know what
the op was you were looking for?
-One way to do this is to inject a rare call somewhere near what you're looking
+One way to do this is to inject a rare call somewhere near what you're looking
for. For example, you could add C<study> before your method:
study;
(gdb) break Perl_pp_study
And then step until you hit what you're
-looking for. This works well in a loop
+looking for. This works well in a loop
if you want to only break at certain iterations:
for my $c (1..100) {
=head2 Using gdb to look at what the parser/lexer are doing
-If you want to see what perl is doing when parsing/lexing your code, you can
+If you want to see what perl is doing when parsing/lexing your code, you can
use C<BEGIN {}>:
print "Before\n";
If you want to see what the parser/lexer is doing inside of C<if> blocks and
the like you need to be a little trickier:
- if ($a && $b && do { BEGIN { study } 1 } && $c) { ... }
+ if ($a && $b && do { BEGIN { study } 1 } && $c) { ... }
=head1 SOURCE CODE STATIC ANALYSIS
projects, and they give out accounts to open source developers to the
defect databases.
+There is Coverity setup for the perl5 project:
+L<https://scan.coverity.com/projects/perl5>
+
+=head2 HP-UX cadvise (Code Advisor)
+
+HP has a C/C++ static analyzer product for HP-UX caller Code Advisor.
+(Link not given here because the URL is horribly long and seems horribly
+unstable; use the search engine of your choice to find it.) The use of
+the C<cadvise_cc> recipe with C<Configure ... -Dcc=./cadvise_cc>
+(see cadvise "User Guide") is recommended; as is the use of C<+wall>.
+
=head2 cpd (cut-and-paste detector)
The cpd tool detects cut-and-paste coding. If one instance of the
The valgrind tool can be used to find out both memory leaks and illegal
heap memory accesses. As of version 3.3.0, Valgrind only supports Linux
-on x86, x86-64 and PowerPC and Darwin (OS X) on x86 and x86-64). The
+on x86, x86-64 and PowerPC and Darwin (OS X) on x86 and x86-64. The
special "test.valgrind" target can be used to run the tests under
valgrind. Found errors and memory leaks are logged in files named
F<testfile.valgrind> and by default output is displayed inline.
Note that the above two invocations will be very verbose as reachable
memory and leak-checking is enabled by default. If you want to just see
pure errors, try:
-
+
VG_OPTS='-q --leak-check=no --show-reachable=no' TEST_JOBS=9 \
make test.valgrind
does set this to 2, and this is what you need to do too, if you don't
want to see the "global leaks": For example, for running under valgrind
- env PERL_DESTRUCT_LEVEL=2 valgrind ./perl -Ilib t/foo/bar.t
+ env PERL_DESTRUCT_LEVEL=2 valgrind ./perl -Ilib t/foo/bar.t
(Note: the mod_perl apache module uses also this environment variable
for its own purposes and extended its semantics. Refer to the mod_perl
read $ENV{PERL_MEM_LOG} to determine whether to log the event, and if
so how:
- $ENV{PERL_MEM_LOG} =~ /m/ Log all memory ops
- $ENV{PERL_MEM_LOG} =~ /s/ Log all SV ops
- $ENV{PERL_MEM_LOG} =~ /t/ include timestamp in Log
- $ENV{PERL_MEM_LOG} =~ /^(\d+)/ write to FD given (default is 2)
+ $ENV{PERL_MEM_LOG} =~ /m/ Log all memory ops
+ $ENV{PERL_MEM_LOG} =~ /s/ Log all SV ops
+ $ENV{PERL_MEM_LOG} =~ /t/ include timestamp in Log
+ $ENV{PERL_MEM_LOG} =~ /^(\d+)/ write to FD given (default is 2)
Memory logging is somewhat similar to C<-Dm> but is independent of
C<-DDEBUGGING>, and at a higher level; all uses of Newx(), Renew(), and
https://perl5.git.perl.org / perl5.git / blobdiff