avoid -Wall warning in apr_md5.c

[André Malo <nd...@perlig.de>]

Just got a report via PM about a gcc warning during 2.0.46 compile:

System:
gcc: 2.95.3
Linux 2.4.18 Conectiva 8

configured with worker MPM.

apr_md5.c:688: warning: `crypt_mutex_lock' defined but not used
apr_md5.c:693: warning: `crypt_mutex_unlock' defined but not used

The attached patch should avoid these, shouldn't it? (untested).

nd
-- 
"Eine Eieruhr", erklärt ihr Hermann, "besteht aus einem Ei. Du nimmst
das Ei und kochst es. Wenn es hart ist, sind fünf Minuten um. Dann weißt
du, daß die Zeit vergangen ist."
                             -- Hannes Hüttner in "Das Blaue vom Himmel"

Re: avoid -Wall warning in apr_md5.c

[Cliff Woolley <jw...@virginia.edu>]

On Thu, 29 May 2003, [ISO-8859-1] Andr� Malo wrote:

> configured with worker MPM.
> apr_md5.c:688: warning: `crypt_mutex_lock' defined but not used
> apr_md5.c:693: warning: `crypt_mutex_unlock' defined but not used

I was seeing the same thing on rh80 during 2.0.46 release testing, but
deemed it not a showstopper.  It should be fixed, I agree.

Re: avoid -Wall warning in apr_md5.c

[Jeff Trawick <tr...@attglobal.net>]

André Malo wrote:
> Just got a report via PM about a gcc warning during 2.0.46 compile:
> 
> System:
> gcc: 2.95.3
> Linux 2.4.18 Conectiva 8
> 
> configured with worker MPM.
> 
> apr_md5.c:688: warning: `crypt_mutex_lock' defined but not used
> apr_md5.c:693: warning: `crypt_mutex_unlock' defined but not used
> 
> The attached patch should avoid these, shouldn't it? (untested).

seems very likely, but I haven't tested it either :)

I think some more serious reimplementation is appropriate for that 
function anyway.

I think it would be cleaner if apr_initialize() set up =>1 thread 
mutexes for its use and apr-util's use, and export those via a global 
array and mutex count, then apr_password_validate(), and any other code 
with a similar problem, would use that.

#if APR_HAS_THREADS
struct {
     apr_thread_mutex_t **mutexes;
     int mutex_count;
} apr_private_mutexes;
#endif

count would be guaranteed >= 1

then apr_password_validate() wouldn't have to have its own mutex 
allocation handling; it would just use one of the available internal APR 
mutexes

#if APR_HAS_THREADS && !defined(APU_CRYPT_THREADSAFE)
   apr_thread_mutex_lock(apr_private_mutexes.mutexes[0]);
   crypt();
   apr_thread_mutex_unlock(apr_private_mutexes.mutexes[0]);
#else
   crypt();
#endif