apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr STATUS
Date Thu, 31 May 2001 23:27:15 GMT
Right. What Cliff said.

We aren't going to provide a replacement for it, just say whether it is
available, and get it linked in from the right library (it can live in
several places).

crypt() is a rather poor hash function. We have MD5 and SHA1 instead.

Cheers,
-g

On Thu, May 31, 2001 at 12:37:41AM -0400, Cliff Woolley wrote:
> On Wed, 30 May 2001, Justin Erenkrantz wrote:
> 
> > I think that wherever these other crypto functions go, so should
> > crypt().
> 
> Yeah, but...
> 
> > crypt() is slightly different than the other crypto algorithms as
> > my systems have it as a standard library call.  But, not all systems
> > will have it.
> 
> Which is exactly why it should go in APR and not APR-util.  APR-util only
> contains functions that are complete, portable implementations of their
> respective functionality (eg the SHA1 implementation).  It was born when
> it was decided that APR's focus should be on creating a library that hides
> platform-specific details of functionality (eg locking, mmaps, DSOs, etc)
> that is non-portable.  That's the aim of apr_crypt()... to make a portable
> way to access the system's crypt() if there is one.  If apr_crypt() were
> to be a from-scratch implementation of crypt() that was written with
> inherently portable code, then yes, it would go in apr-util.  But that's
> not the goal, so it goes in APR.
> 
> My $0.02.
> 
> --Cliff
> 
> --------------------------------------------------------------
>    Cliff Woolley
>    cliffwoolley@yahoo.com
>    Charlottesville, VA
> 

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message