-long c = 0;</PRE
-></TD
-></TR
-></TABLE
-><P
-><I
-CLASS="EMPHASIS"
->Instead of:</I
-></P
-><P
->long a, b, c;</P
-><P
-><I
-CLASS="EMPHASIS"
->Explanation:</I
-> - there is more room for comments on the
- individual variables - easier to add new variables without
- messing up the original ones - when searching on a variable to
- find its type, there is less clutter to "visually"
- eliminate</P
-><P
-><I
-CLASS="EMPHASIS"
->Exceptions:</I
-> when you want to declare a bunch of loop
- variables or other trivial variables; feel free to declare them
- on 1 line. You should, although, provide a good comment on
- their functions.</P
-><P
-><I
-CLASS="EMPHASIS"
->Status:</I
-> developer-discretion.</P
-></DIV
-><DIV
-CLASS="SECT3"
-><H3
-CLASS="SECT3"
-><A
-NAME="S42"
->6.7.7. Use malloc/zalloc sparingly</A
-></H3
-><P
-><I
-CLASS="EMPHASIS"
->Explanation:</I
-></P
-><P
->Create a local struct (on the stack) if the variable will
- live and die within the context of one function call.</P
-><P
->Only "malloc" a struct (on the heap) if the variable's life
- will extend beyond the context of one function call.</P
-><P
-><I
-CLASS="EMPHASIS"
->Example:</I
-></P
-><TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
->If a function creates a struct and stores a pointer to it in a
-list, then it should definitely be allocated via `malloc'.</PRE
-></TD
-></TR
-></TABLE
-></DIV
-><DIV
-CLASS="SECT3"
-><H3
-CLASS="SECT3"
-><A
-NAME="S43"
->6.7.8. The Programmer Who Uses 'malloc' is
- Responsible for Ensuring 'free'</A
-></H3
-><P
-><I
-CLASS="EMPHASIS"
->Explanation:</I
-></P
-><P
->If you have to "malloc" an instance, you are responsible for
- insuring that the instance is `free'd, even if the deallocation
- event falls within some other programmer's code. You are also
- responsible for ensuring that deletion is timely (i.e. not too
- soon, not too late). This is known as "low-coupling" and is a
- "good thing (tm)". You may need to offer a
- free/unload/destuctor type function to accommodate this.</P
-><P
-><I
-CLASS="EMPHASIS"
->Example:</I
-></P
-><TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
->int load_re_filterfile( struct client_state *csp ) { ... }
-static void unload_re_filterfile( void *f ) { ... }</PRE
-></TD
-></TR
-></TABLE
-><P
-><I
-CLASS="EMPHASIS"
->Exceptions:</I
-></P
-><P
->The developer cannot be expected to provide `free'ing
- functions for C run-time library functions ... such as
- `strdup'.</P
-><P
-><I
-CLASS="EMPHASIS"
->Status:</I
-> developer-discretion. The "main" use of this
- standard is for allocating and freeing data structures (complex
- or nested).</P
-></DIV
-><DIV
-CLASS="SECT3"
-><H3
-CLASS="SECT3"
-><A
-NAME="S44"
->6.7.9. Add loaders to the `file_list' structure
- and in order</A
-></H3
-><P
-><I
-CLASS="EMPHASIS"
->Explanation:</I
-></P
-><P
->I have ordered all of the "blocker" file code to be in alpha
- order. It is easier to add/read new blockers when you expect a
- certain order.</P
-><P
-><I
-CLASS="EMPHASIS"
->Note:</I
-> It may appear that the alpha order is broken in
- places by POPUP tests coming before PCRS tests. But since
- POPUPs can also be referred to as KILLPOPUPs, it is clear that
- it should come first.</P
-></DIV
-><DIV
-CLASS="SECT3"
-><H3
-CLASS="SECT3"
-><A
-NAME="S45"
->6.7.10. "Uncertain" new code and/or changes to
- existing code, use FIXME</A
-></H3
-><P
-><I
-CLASS="EMPHASIS"
->Explanation:</I
-></P
-><P
->If you have enough confidence in new code or confidence in
- your changes, but are not *quite* sure of the repercussions,
- add this:</P
-><P
->/* FIXME: this code has a logic error on platform XYZ, *
- attempting to fix */ #ifdef PLATFORM ...changed code here...
- #endif</P
-><P
->or:</P
-><P
->/* FIXME: I think the original author really meant this...
- */ ...changed code here...</P
-><P
->or:</P
-><P
->/* FIXME: new code that *may* break something else... */
- ...new code here...</P
-><P
-><I
-CLASS="EMPHASIS"
->Note:</I
-> If you make it clear that this may or may not
- be a "good thing (tm)", it will be easier to identify and
- include in the project (or conversely exclude from the
- project).</P
-></DIV
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="S46"
->6.8. Addendum: Template for files and function
- comment blocks:</A
-></H2
-><P
-><I
-CLASS="EMPHASIS"
->Example for file comments:</I
-></P
-><TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
->const char FILENAME_rcs[] = "$Id: developer-manual.sgml,v 1.37 2002/04/26 17:23:29 swa Exp $";
+long c = 0;
+</pre>
+ </td>
+ </tr>
+ </table>
+ <p>
+ <span class="emphasis"><i class="EMPHASIS">Instead of:</i></span>
+ </p>
+ <p>
+ long a, b, c;
+ </p>
+ <p>
+ <span class="emphasis"><i class=
+ "EMPHASIS">Explanation:</i></span> - there is more room for
+ comments on the individual variables - easier to add new
+ variables without messing up the original ones - when searching
+ on a variable to find its type, there is less clutter to
+ "visually" eliminate
+ </p>
+ <p>
+ <span class="emphasis"><i class="EMPHASIS">Exceptions:</i></span>
+ when you want to declare a bunch of loop variables or other
+ trivial variables; feel free to declare them on one line. You
+ should, although, provide a good comment on their functions.
+ </p>
+ <p>
+ <span class="emphasis"><i class="EMPHASIS">Status:</i></span>
+ developer-discretion.
+ </p>
+ </div>
+ <div class="SECT3">
+ <h3 class="SECT3">
+ <a name="S42">4.7.6. Use malloc/zalloc sparingly</a>
+ </h3>
+ <p>
+ <span class="emphasis"><i class=
+ "EMPHASIS">Explanation:</i></span>
+ </p>
+ <p>
+ Create a local struct (on the stack) if the variable will live
+ and die within the context of one function call.
+ </p>
+ <p>
+ Only "malloc" a struct (on the heap) if the variable's life will
+ extend beyond the context of one function call.
+ </p>
+ <p>
+ <span class="emphasis"><i class="EMPHASIS">Example:</i></span>
+ </p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+<pre class="PROGRAMLISTING">
+If a function creates a struct and stores a pointer to it in a
+list, then it should definitely be allocated via `malloc'.
+</pre>
+ </td>
+ </tr>
+ </table>
+ </div>
+ <div class="SECT3">
+ <h3 class="SECT3">
+ <a name="S43">4.7.7. The Programmer Who Uses 'malloc' is
+ Responsible for Ensuring 'free'</a>
+ </h3>
+ <p>
+ <span class="emphasis"><i class=
+ "EMPHASIS">Explanation:</i></span>
+ </p>
+ <p>
+ If you have to "malloc" an instance, you are responsible for
+ insuring that the instance is `free'd, even if the deallocation
+ event falls within some other programmer's code. You are also
+ responsible for ensuring that deletion is timely (i.e. not too
+ soon, not too late). This is known as "low-coupling" and is a
+ "good thing (tm)". You may need to offer a free/unload/destructor
+ type function to accommodate this.
+ </p>
+ <p>
+ <span class="emphasis"><i class="EMPHASIS">Example:</i></span>
+ </p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+<pre class="PROGRAMLISTING">
+int load_re_filterfile(struct client_state *csp) { ... }
+static void unload_re_filterfile(void *f) { ... }
+</pre>
+ </td>
+ </tr>
+ </table>
+ <p>
+ <span class="emphasis"><i class="EMPHASIS">Exceptions:</i></span>
+ </p>
+ <p>
+ The developer cannot be expected to provide `free'ing functions
+ for C run-time library functions ... such as `strdup'.
+ </p>
+ <p>
+ <span class="emphasis"><i class="EMPHASIS">Status:</i></span>
+ developer-discretion. The "main" use of this standard is for
+ allocating and freeing data structures (complex or nested).
+ </p>
+ </div>
+ <div class="SECT3">
+ <h3 class="SECT3">
+ <a name="S44">4.7.8. Add loaders to the `file_list' structure and
+ in order</a>
+ </h3>
+ <p>
+ <span class="emphasis"><i class=
+ "EMPHASIS">Explanation:</i></span>
+ </p>
+ <p>
+ I have ordered all of the "blocker" file code to be in alpha
+ order. It is easier to add/read new blockers when you expect a
+ certain order.
+ </p>
+ <p>
+ <span class="emphasis"><i class="EMPHASIS">Note:</i></span> It
+ may appear that the alpha order is broken in places by POPUP
+ tests coming before PCRS tests. But since POPUPs can also be
+ referred to as KILLPOPUPs, it is clear that it should come first.
+ </p>
+ </div>
+ <div class="SECT3">
+ <h3 class="SECT3">
+ <a name="S45">4.7.9. "Uncertain" new code and/or changes to
+ existing code, use XXX</a>
+ </h3>
+ <p>
+ <span class="emphasis"><i class=
+ "EMPHASIS">Explanation:</i></span>
+ </p>
+ <p>
+ If you have enough confidence in new code or confidence in your
+ changes, but are not *quite* sure of the repercussions, add this:
+ </p>
+ <p>
+ /* XXX: this code has a logic error on platform XYZ, * attempting
+ to fix */ #ifdef PLATFORM ...changed code here... #endif
+ </p>
+ <p>
+ or:
+ </p>
+ <p>
+ /* XXX: I think the original author really meant this... */
+ ...changed code here...
+ </p>
+ <p>
+ or:
+ </p>
+ <p>
+ /* XXX: new code that *may* break something else... */ ...new
+ code here...
+ </p>
+ <p>
+ <span class="emphasis"><i class="EMPHASIS">Note:</i></span> If
+ you make it clear that this may or may not be a "good thing
+ (tm)", it will be easier to identify and include in the project
+ (or conversely exclude from the project).
+ </p>
+ </div>
+ </div>
+ <div class="SECT2">
+ <h2 class="SECT2">
+ <a name="S46">4.8. Addendum: Template for files and function
+ comment blocks:</a>
+ </h2>
+ <p>
+ <span class="emphasis"><i class="EMPHASIS">Example for file
+ comments:</i></span>
+ </p>
+ <table border="0" bgcolor="#E0E0E0" width="100%">
+ <tr>
+ <td>
+<pre class="PROGRAMLISTING">
+const char FILENAME_rcs[] = "$I<!-- Break CVS Substitution -->d$";