apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: cvs commit: apr STATUS
Date Thu, 31 May 2001 04:37:41 GMT
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 Woolley
   Charlottesville, VA

View raw message