perlhack.pod: small porta-tweaks (this time without pod2man :-)
[p5sagit/p5-mst-13.2.git] / pod / perlhack.pod
index 77df549..ffce50f 100644 (file)
@@ -450,7 +450,7 @@ When you keep in sync with bleadperl, the pumpking would love to
 I<see> that the community efforts really work. So after each of his
 sync points, you are to 'make test' to check if everything is still
 in working order. If it is, you do 'make ok', which will send an OK
-report to perlbug@perl.org. (If you do not have access to a mailer
+report to I<perlbug@perl.org>. (If you do not have access to a mailer
 from the system you just finished successfully 'make test', you can
 do 'make okfile', which creates the file C<perl.ok>, which you can
 than take to your favourite mailer and mail yourself).
@@ -570,22 +570,17 @@ other diff variants.
 
 =head2 Perlbug administration
 
-There is a single remote administrative interface for modifying bug status, 
-category, open issues etc. using the B<RT> I<bugtracker> system, maintained
-by I<Robert Spier>.  Become an administrator, and close any bugs you can get 
+There is a single remote administrative interface for modifying bug status,
+category, open issues etc. using the B<RT> bugtracker system, maintained
+by Robert Spier.  Become an administrator, and close any bugs you can get
 your sticky mitts on:
 
-       http://rt.perl.org
-
-The bugtracker mechanism for B<perl5> bugs in particular is at:
-
-       http://bugs6.perl.org/perlbug
+       http://rt.perl.org/rt3/
 
 To email the bug system administrators:
 
        "perlbug-admin" <perlbug-admin@perl.org>
 
-
 =head2 Submitting patches
 
 Always submit patches to I<perl5-porters@perl.org>.  If you're
@@ -620,7 +615,7 @@ To report a bug in Perl, use the program I<perlbug> which comes with
 Perl (if you can't get Perl to work, send mail to the address
 I<perlbug@perl.org> or I<perlbug@perl.com>).  Reporting bugs through
 I<perlbug> feeds into the automated bug-tracking system, access to
-which is provided through the web at http://bugs.perl.org/ .  It
+which is provided through the web at http://rt.perl.org/rt3/ .  It
 often pays to check the archives of the perl5-porters mailing list to
 see whether the bug you're reporting has been reported before, and if
 so whether it was considered a bug.  See above for the location of
@@ -628,8 +623,8 @@ the searchable archives.
 
 The CPAN testers ( http://testers.cpan.org/ ) are a group of
 volunteers who test CPAN modules on a variety of platforms.  Perl
-Smokers ( http://archives.develooper.com/daily-build@perl.org/ )
-automatically tests Perl source releases on platforms with various
+Smokers ( http://www.nntp.perl.org/group/perl.daily-build )
+automatically test Perl source releases on platforms with various
 configurations.  Both efforts welcome volunteers.
 
 It's a good idea to read and lurk for a while before chipping in.
@@ -679,11 +674,9 @@ wanting to go about Perl development.
 
 =item The perl5-porters FAQ
 
-This should be available from http://simon-cozens.org/writings/p5p-faq ;
-alternatively, you can get the FAQ emailed to you by sending mail to
-C<perl5-porters-faq@perl.org>. It contains hints on reading perl5-porters,
-information on how perl5-porters works and how Perl development in general
-works.
+This should be available from http://dev.perl.org/perl5/docs/p5p-faq.html .
+It contains hints on reading perl5-porters, information on how
+perl5-porters works and how Perl development in general works.
 
 =back
 
@@ -2404,9 +2397,9 @@ therefore more ways for things to go wrong.  You should try it.
 Introducing (non-read-only) globals
 
 Do not introduce any modifiable globals, truly global or file static.
-They are bad form and break multithreading.  The right way is to
-introduce them as new interpreter variables, see F<intrpvar.h> (at the
-very end for binary compatibility).
+They are bad form and complicate multithreading and other forms of
+concurrency.  The right way is to introduce them as new interpreter
+variables, see F<intrpvar.h> (at the very end for binary compatibility).
 
 Introducing read-only (const) globals is okay, as long as you verify
 with e.g. C<nm libperl.a|egrep -v ' [TURtr] '> (if your C<nm> has
@@ -2417,12 +2410,17 @@ If you want to have static strings, make them constant:
 
   static const char etc[] = "...";
 
-If you want to have arrays of static strings, note carefully
+If you want to have arrays of constant strings, note carefully
 the right combination of C<const>s:
 
     static const char * const yippee[] =
        {"hi", "ho", "silver"};
 
+There is a way to completely hide any modifiable globals (they are all
+moved to heap), the compilation setting C<-DPERL_GLOBAL_STRUCT_PRIVATE>.
+It is not normally used, but can be used for testing, read more
+about it in L<perlhack>.
+
 =item *
 
 Not exporting your new function
@@ -2462,18 +2460,22 @@ reading.  Please test your changes with as many C compilers and
 platforms as possible -- we will, anyway, and it's nice to save
 oneself from public embarrassment.
 
-If using gcc, starting from Perl 5.9.4 Perl core C files will be
-compiled with the C<-std=c89> option which will hopefully catch
-most of these unportabilities.
+If using gcc, you can add the C<-std=c89> option which will hopefully
+catch most of these unportabilities. (However it might also catch
+incompatibilities in your system's header files.)
 
 Use the Configure C<-Dgccansipedantic> flag to enable the gcc
 C<-ansi -pedantic> flags which enforce stricter ANSI rules.
 
+If using the C<gcc -Wall> note that not all the possible
+warnings are given unless you also compile with C<-O>.
+
 Also study L<perlport> carefully to avoid any bad assumptions
 about the operating system, filesystem, and so forth.
 
-You may once in a while try a "make miniperl" to see whether we
+You may once in a while try a "make microperl" to see whether we
 can still compile Perl with just the bare minimum of interfaces.
+(See README.micro.)
 
 Do not assume an operating system indicates a certain compiler.
 
@@ -2539,7 +2541,60 @@ Lvalue casts
   (int)*p = ...;
 
 Simply not portable.  Get your lvalue to be of the right type,
-or maybe use temporary variables.
+or maybe use temporary variables, or dirty tricks with unions.
+
+=item *
+
+Assume B<anything> about structs (especially the ones you
+don't control, like the ones coming from the system headers)
+
+=over 8
+
+=item *
+
+That a certain field exists in a struct
+
+=item *
+
+That no other fields exist besides the ones you know of
+
+=item *
+
+That a field is of certain signedness, sizeof, or type
+
+=item *
+
+That the fields are in a certain order
+
+=over 8
+
+=item *
+
+While C guarantees the ordering specified in the struct definition,
+between different platforms the definitions might differ
+
+=back
+
+=item *
+
+That the sizeof(struct) or the alignments are the same everywhere
+
+=over 8
+
+=item *
+
+There might be padding bytes between the fields to align the fields -
+the bytes can be anything
+
+=item *
+
+Structs are required to be aligned to the maximum alignment required
+by the fields - which for native types is for usually equivalent to
+sizeof() of the field
+
+=back
+
+=back
 
 =item *
 
@@ -2580,6 +2635,21 @@ The gcc option C<-Wendif-labels> warns about the bad variant
 
 =item *
 
+Having a comma after the last element of an enum list
+
+  enum color {
+    CERULEAN,
+    CHARTREUSE,
+    CINNABAR, /* Right here. */
+  };
+
+is not portable.  Leave out the last comma.
+
+Also note that whether enums are implicitly morphable to ints
+varies between compilers, you might need to (int).
+
+=item *
+
 Using //-comments
 
   // This function bamfoodles the zorklator.