My comment has nothing to do with versioning but rather a tendency

to be conservative about things that could possibly fail - given an
unknown implementation.  Our implementation can't fail, but a theoretical
MD5 implementation could.  I've just been bit by too many locations in
httpd where no return code was ever thought possible and we had to
change the API to handle a return code when we did need it.

Note that our md5 implementation has no business being in APR - it
should be in apr-util with our "crypto" stuff there.  The overall goal
of providing random bytes on all platforms (i.e. APR_HAS_RANDOM is always
defined) would mean that we can kick md5 to its appropriate place - see
note about where the fix needs to be.  So, if you "fix" the API, it might
be goodness to move it to apr-util at the same time.


git-svn-id: http://svn.apache.org/repos/asf/apr/apr/trunk@63254 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 4 insertions, 2 deletions

diff --git a/STATUS b/STATUS
index 4761c5bd9..1cb80c456 100644
--- a/STATUS
+++ b/STATUS
@@ -1,5 +1,5 @@
 APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS:			-*-text-*-
-Last modified at [$Date: 2002/04/13 06:12:33 $]
+Last modified at [$Date: 2002/04/13 06:34:08 $]
 
 Release:
 
@@ -344,10 +344,12 @@ Stuff waiting for code thawing after Beta 1:
       versioned, this api change is [somewhat] painful for httpd.
       Status: Still in discussion, current leanings appear to be
         Bill Stoddard -0.5 (?)
-        Justin Erenkrantz -1
         Sander Striker -1 or -0.5 (?)
         Greg Stein +1
         Karl Fogel +1
       (Not sure if the negatives would stay negative given that the
       change would now wait for the library versioning thing described
       above, though.)
+        Justin says: If you do this, please move it into apr-util where md5
+                     belongs!  You'll have to address the random issue in
+                     misc/unix/getuuid.c that forces md5 to be in APR.