Federico Di Gregorio <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
