apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jerenkra...@apache.org
Subject cvs commit: apr-site patches.html
Date Tue, 05 Jun 2001 18:26:11 GMT
jerenkrantz    01/06/05 11:26:11

  Modified:    .        patches.html
  As discussed on dev@apr - 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>
      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

View raw message