Re: libpq not reentrant

Federico Di Gregorio <fog(at)initd(dot)org> writes:
> so the right library is already detected. the function is called
> des_crypt and is completely compatible with std. i think that a

> AC_SEARCH_LIBS(crypto, des_crypt)

> in configure.in will suffice. then:

> #ifdef HAVE_DES_CRYPT
> #define crypt des_crypt
> #endif

Hmm. If it uses the same API as crypt(), how can it be reentrant ---
is it malloc'ing the result string? The resulting leak probably isn't
significant for libpq's purposes, but I'm curious to know.

> in the right file will do the trick. (i know this is not a real patch,
> sorry. i can make one later at home if you need.)

Please put together and test a complete patch. I don't really care for
the #define crypt, BTW --- seems too likely to cause problems. I'd
suggest #ifdef'ing around the call to crypt().

Also, if the result string is malloc'd, code along the lines of

#ifdef HAVE_DES_CRYPT
foo = des_crypt(...);
#else
foo = crypt(...);
#endif

... use foo ...

#ifdef HAVE_DES_CRYPT
/* des_crypt returns malloc'd string */
free(foo);
#endif

doesn't seem too unreasonable. Or even

#ifdef HAVE_DES_CRYPT
foo = des_crypt(...);
#else
foo = strdup(crypt(...));
#endif

... use foo ...

free(foo);

which would at least narrow the window for problems when using
non-reentrant crypt.

regards, tom lane