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 [EMAIL PROTECTED] Charlottesville, VA
