You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Greg Stein <gs...@lyra.org> on 2001/06/01 01:27:15 UTC
Re: cvs commit: apr STATUS
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/