-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 1 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.7. 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.8. 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.9. 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.10. "Uncertain" new code and/or changes to
- existing code, use FIXME</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
->/* 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
-><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[] = "$Id: coding.html,v 1.19.2.7 2004/01/31 00:05:44 oes 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" id="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" id="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" id="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" id="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" id="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">/*********************************************************************