jerenkrantz 01/06/05 11:26:11
Modified: . patches.html
Log:
As discussed on [EMAIL PROTECTED] - add a comment about the assert/checking
input debate. Our policy is "don't check input values." Feel free
to change the wording. It's something, but we've had two longish
threads in the last day about this...
Also, let people know that they can (should) resubmit patches if no
one gives feedback.
Revision Changes Path
1.2 +12 -1 apr-site/patches.html
Index: patches.html
===================================================================
RCS file: /home/cvs/apr-site/patches.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- patches.html 2000/12/03 18:04:24 1.1
+++ patches.html 2001/06/05 18:26:10 1.2
@@ -38,6 +38,15 @@
a strchr() faster than an index()? Etc. Of course it'd be nice if we
had a real document describing this all, but we don't yet.</P>
+ <P>
+ One notable standard that has been adopted within APR functions (and
+ is partly due to APR's httpd lineage) is that the input values do not
+ need to be checked for correctness. It is the responsibility of the
+ calling program that uses APR to ensure that the input parameters
+ are what APR expects. If the input parameters are invalid (NULL, for
+ example), APR functions will likely produce a segfault when it
+ attempts to reference these variables.</P>
+
<HR>
<H2>
Patch Format
@@ -69,7 +78,9 @@
line, so everyone knows it's a patch. However, it's not guaranteed
that your Patch will find an advocate within the developers' group;
if we're too busy working on something else or everyone's on
- vacation, it could get lost in the noise.
+ vacation, it could get lost in the noise. Feel free to resubmit your
+ patch in a week or so if you have not yet received any feedback from
+ the developers' group.
<P>Also, there are often times when the core developers are in
"feature freeze", when they are trying to iron out the remaining
