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 > [EMAIL PROTECTED] > Charlottesville, VA > -- Greg Stein, http://www.lyra.org/