-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">const char FILENAME_rcs[] = "$I<!-- Break CVS Substitution -->d$";
+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$";